Пятачок пишет:

У меня сложилось впечатление, что рейт по проекту где-то $5-$7. Правильно?

> Некоторые тут возмущались тем, что заказчик не хочет оплачивать время,
> затраченное на исправление багов программиста. А вот такой разговор с
> представителем заказчика сложился у меня. Собственно коменты с моей
> стороны излишни. Я просто в ауте.

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

Я не в ауте. ИМХО, заказчик вполне вменяем и не ждет от Вас чуда в виде
безгрешного кода без ошибок, насколько я понял с процитированных Вами
разговора. Почему Вы ожидаете, что заказчик будет безгрешен и напишет
ТЗ, которое закрывает все, что только можно? Для невозникновения
подобных проблем в будущем: при возникновении хоть малейших подозрений,
что Вы делаете что-то не то, вне зависимости от ТЗ, задавайте вопросы
заказчику до тех пор, пока не поймете, почему именно так. Кстати, в ходе
подобных разговоров, зачастую, выясняется, что делать можно/нужно
намного проще. Не бойтесь и не жадничайте -- снижайте цену проекта. Это
окупается очень быстро.

Теперь по текущей ситуации. Что я бы сделал. Вам стоит откатиться назад
и выяснить, что же на самом деле произошло. "Вот в этом, конкретном,
месте мы неправильно поняли друг друга. Я протормозил, вы прошлепали."
Признать свою ошибку, заставить заказчика признать свою. Разделить
ответственность (например снизить рейт вдвое) и исправить.

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

Здравствуйте, Пятачок, Вы писали:

П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.

я так понимаю, ты ждешь что мы тоже будем "в ауте"? Тогда намекни хоть — как ты с аутлуком разошелся?

ОНН>Лучше давайте координаты заказчика — сюда,
ОНН>чтоб другие не нарвались

Пока не буду, может еще обойдется

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

Здравствуйте, aik, Вы писали:

aik>я так понимаю, ты ждешь что мы тоже будем "в ауте"?
Да не, ничего не жду, просто захотелось с кем-то поделиться, крик души можно сказать.

>Тогда намекни хоть — как ты с аутлуком разошелся?
С аутлуком я сам не до конца понимаю чего они хотят. В понедельник заказчик даст коменты, тогда станет ясно. Сейчас есть система оповещения, которая раз в пять минут пробегается по значениям из базы и если время какого-то действия пришло, то показывает оповещение. "Как в аутлуке" — я понял что им нужно чтобы сообщение показывалось сразу же, а не раз в 5 мин.

А что собственно удивляет то? Конечно все предусмотреть нельзя в ТЗ. В 90% случаев это именно так и есть.

Другое дело, что это нужно СРАЗУ донести до заказчика, и строить рабочий процесс в соответсвии с этим фактом. Т.е. чтото типа — ваши желания, ради бога, за ваши деньги что угодно. Т.е. нету фенечки в тз, прикидываете стоимость изходя из вашего нормочаса, и пожалуйста, прайс заказчику — фенечка такая то, стокота часов, стоит столькото.

Здравствуйте, Пятачок, Вы писали:

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

Сделайте кое-что,
а по ходу дела ненавязчиво дайте понять,
что у Вас телефон и интернет за неуплату отключают

Здравствуйте, Пятачок, Вы писали:

П>"Как в аутлуке" — я понял что им нужно чтобы сообщение показывалось сразу же, а не раз в 5 мин.

В аутлуке
(если я правильно понимаю, что речь идёт о MS Outlook,
а не о каком-то из ваших методов или таблиц)
сообщение показывается не сразу,
а в соответствии с периодом,
выставляемым в настройках.

Здравствуйте, Пятачок, Вы писали:

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

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, Pzz, Вы писали:

Pzz>>2. Может ли он это использовать, не оплатив
Pzz>>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.

ДГ>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.

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

Здравствуйте, Pzz, Вы писали:

ДГ>>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.

Pzz>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать. А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...

Лично я стараюсь отдавать исходники только после полной оплаты. До этого момента поставляются только бинарники.

Здравствуйте, Пятачок, Вы писали:

П>Вот самое обидное, что я уже все сделал, что они там еще хотят — не особо понятно, а денег мне пока так и не заплатили. И боюсь что если начну препираться, то все дойдет до того, что они оставят и деньги и программу себе. В программе может еще с остались недоделки, но и с ними можно успешно работать.

Ну в общем-то вы сами виноваты. Лоханулись, притом не единожды.

1. Перед стартом проекта надо довести до заказчика план работ и смету. Оговорить, что все дополнительные работы вы с готовностью выполните, но за дополнительную оплату и желательно в отдельной фазе проекта, после завершения и проплаты основных работ. Не согласны? До свидания.
2. Стоило оговорить майлстоны. На каждом из которых вы демонстрируете результаты, а заказчик выполняет частичную оплату. Такой подход минимизирует риски кидалова, ну или по крайней мере минимизирует ущерб от кидалова. Заказчик тянет резину с оплатой майлстона? Уведомляете его о приостановке работ.
3. Не стоит отдавать исходники программы заказчику до финальной оплаты. И подсадить "жучков", сделав программу триальной, тоже можно.

П>Еще поражает отношение заказчика — типа вот мы тут у тебя баги нашли, ай-ай-ай, как же так, пишешь и с ошибками. Боже мой, судя по всему они вообще там не имеют представления о нормальном процессе программописания

Ну дак если они не имеют предстваления, то кто им объяснит? Надо вежливо и с достоинством рассказать, что писать программы совсем без ошибок еще никому не удавалось. Вы понимаете озабоченность заказчика и готовы усилить контроль качества, добавив в проект фазу тестирования сборок или даже введя в проект тестера. Заказчик готов оплачивать эти дополнительные услуги?

И еще: твердолобость и умение встать в позицию — очень полезные умения в бизнесе. Если заказчик вас начал прогибать как ему хочется, то потом переломить ситуацию очень сложно.

Чтобы не было такого разговора надо пользоваться методикой XP. RUP и прочие MSF себя не оправдывают — особенно для небольших команд.
А при XP — такие разговоры в принципе не возможны.

Здравствуйте, Пятачок, Вы писали:

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

Здравствуйте, Пятачок, Вы писали:

П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.


Напоминает анекдот о негре, который стал унитазом в женском туалете — всё строго по ТЗ, но результат совсем не тот, который ожидался заказчиком. Расскажите этот анекдот заказчику и объясните, что должна быть описана каждая мелочь. Спрашивайте его сейчас и в будующем (в процессе доработки программы) обо всём, что может быть понято неоднозначно, а так-же, составьте договор, который будет описывать, как должны вносится изменения и дополнения к ТЗ.

Следующим заказчикам объясните это заранее. Всё тщательно обговаривайте и совместно работайте над ТЗ ещё до того, как будут написана первая строка программы. Это сильно облегчит жизнь.

Здравствуйте, AleksandrN, Вы писали:

AN>Напоминает анекдот о негре, который стал унитазом в женском туалете — всё строго по ТЗ, но результат совсем не тот, который ожидался заказчиком. Расскажите этот анекдот заказчику и объясните, что должна быть описана каждая мелочь. Спрашивайте его сейчас и в будующем (в процессе доработки программы) обо всём, что может быть понято неоднозначно, а так-же, составьте договор, который будет описывать, как должны вносится изменения и дополнения к ТЗ.

AN>Следующим заказчикам объясните это заранее. Всё тщательно обговаривайте и совместно работайте над ТЗ ещё до того, как будут написана первая строка программы. Это сильно облегчит жизнь.
Сильно усложнит жизнь. Обоим. В лучшем случае удастся стрясти денег с заказчика и ничего [полезного] не сделать. В худшем — просто ничего [полезного] не сделать.

Здравствуйте, Пятачок, Вы писали:

П>Еще поражает отношение заказчика — типа вот мы тут у тебя баги нашли, ай-ай-ай, как же так, пишешь и с ошибками. Боже мой, судя по всему они вообще там не имеют представления о нормальном процессе программописания
А что тут поражает? Если заказчик оплатил фазу QA, то он вправе расчитывать на полное отсутствие багов (за редчайшим исключением). Если же QA оплачен небыл, то заказчик знает, что QA выполняется его же силами, а фикс багов — в зависимости от контракта.
ИМХО вполне адекватная реакция. Вы же не лабу в школе сдаёте, а комерческий продукт.

Практика работы моей конторы показывает, что прописывание деталей в ТЗ, договоры доработки и пр. — это не работает, а только съедает время и нервы.
Это объясняется очень просто: почасовая оплата вместо результата работает только в двух местах:
1. Две крупные организации, одна наняла другую, два друга пожали руки, — есть профсоюзы, эристы и прочий народ, который может наехать. Контракт подписан на годы, при этом оценивались личные отношения, общая стоимость, репутация конторы, и о каждом конкретном отработанном часе никто не заморачивается — оплачиваются тысячи часов в месяц, и если что не так, даются обещания всё исправить. а если начинаются ругачки — в 40% случаев это конец совместному бизнесу;
2. Всякие тренеры, учителя и психологи. Они как-то хитрожопо выбили себе такое право ... тёмная история. Но тут деньги из рук в руки и, опять же, если пошла ругачка — конец отношениям.
(ну может еще есть примеры ... глубоко я над этим не думал)

Все эти договора с пунктами оплаты, этапами и человеко/часами за n рублей — всё это слизано с больших договоров и больших компаний. Каюсь, сам наступал на эти грабли неоднократно. Так можно работать, но это совершенно непродуктивно. Никакого толкового бизнеса.

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

Что ты подумаешь, если к тебе привезут заказ на 2 дня позже и скажут, что вот вы тут нам не сказали, как сложно к вам добираться, я тут еще 2 раза за маршрутку платил — давайте доплачивайте. Или если позвонят и скажут, что вот книжка ваша с Озона ... она как-то не так была упакована и там таможня, то да сё — плати. Оба варианта можно себе представить и в жизни, но такие компании-неудачники долго на рынке не задержатся. Второй раз ты туда звонить не станешь.

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

То, что делает транспортная компания называется управлением рисками перевозки. Она правильно считает цену, она строит своих сотрудников. Управление такими рисками — задача поставщика, а не покупателя.

Какой отсюда совет для софтверной индустрии, если ты фрилансер или маленькая компания. Так же как ты не берешь с заказчика денег за свою саморекламу, за сертификаты и прочее, ты должен стараться максимально решить за него все его проблемы и сделать так, как будто этих проблем нет. Конечно, это должно быть заложено в оплату. Ты должен прекрасно понимать, что ТЗ и стоимость проекта — это не реальные вещи — это мифические штуки, определенный ритуал, из которого нужно вытянуть максимум полезного. Максимум полезного такой: в ТЗ нужно описать функциональные требования к софту, а не конкретику. В договоре нужно прописать условия оплаты, условия выплаты денег до срока по личной договоренности и условия расставания (плохого или хорошего).

То, что ТЗ — это не система, а сумма взята с потолка — все прекрасно понимают. Это можно прямо говорить заказчику. Как определять цену? Она должна превышать кажущююся первоначально стоимость исходя из мифических трудозатрат на некоторый процент типа 30 или 50. Закладывайся так, чтобы даже в самом ужасном случае ты ничего не потерял. Ну или.. 10 рублей там. Имеется в виду ужасный проект, ужасный заказчик, но не твоя ужасно сделаная работа, конечно. Реально-то договоренность идет о рыночной цене, у заказчика есть свое представление о стоимости, и тут важна бизнес-схватка. нужно знать цены на рынке, знать что там реально за эти деньги идет и т.д. чтобы иметь внутреннюю уверенность, т.к. всё равно все эти рыночные цены и обещания — по большому счету пока враньё. Только упорный труд и деловая этика могут сделать из этого вранья что-то удовлетворительное для обоих.

Поэтому если у заказчика в голове есть цифра $10000, допустим, и он за нее железно держится, то нужно просто оценить — хочешь ли ты делать еще один геморный проект за такую сумму + получить еще референс, т.е. еще одного довольного заказчика (референсы, которые просто "сделаны" — их можно просто придумать и вписать в портфолию. важен именно довольный заказчик, которого можно пригласить на встречу, попросить прорекламировать себя и т.д.). А на заявления типа "вот тут мы упростили задачу, это снимает 3 дня, значит уже не $5000, а $4500 — верно?" нужно честно отвечать, что все эти дни сейчас — полная ерунда, всё на глаз, что это ваше упрощение ... крохоборство, ничего щас оценить нельзя, а для снижения стоимости нужно не по сусекам скрести, а, например, предоплату сделать не 50%, а 75 — вот, типа, разговор не мальчика, но мужа.

Нужно чётко запомнить две мантры и транслировать их на переговорах:
1. Я решу за вас все ваши проблемы, все непонятки по ходу проекта будут прояснены, и вы будете полностью удовлетворены результатом за заранее оговоренную цену. Я ручаюсь за это своим опытом и соображалкой в теме;
2. Я делаю это ради денег, это бизнес, поэтому вопрос денег очень важен, и без денег ничего двигаться не будет. Это не означает шантаж, это просьба о платежной дисциплине.

Уверяю, заказчик в подавляющем числе случаев не жадничает, а беспокоится о результате и боится попасть на кидалово. Если контора затевает IT проект, то его стоимость — это не 50% её доходов уж точно. Дай бог 1%. А для тебя это все деньги, что есть и будут. Именно это вызывает в тебе обиду на заказчика, но заказчик, подписывая договора и т.д. не хочет иметь дело с обиженным работником — ему нужен бизнесмен, который решит их проблемы, вытерет все сопли, разгонит привидения метлой и т.д.

В этой ситуации я полностью на стороне заказчика. Его цель — максимально полно решить свою бизнес-задачу при помощи написанной программы. При этом получить решение в ожидаемые сроки и уложиться в бюджет. Все остальное его не касается и не должно касаться.

ТЗ — бумажка для прикрытия задницы в случае провала проекта. Она является устаревшей уже на момент написания. Разработка точного и всеобъемлющего ТЗ, а также поддержка его в актуальном состоянии, может занять больше времени, чем написание программы.

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

Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.

Здравствуйте, abibok, Вы писали
A>Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.

извините, но написанное выше не имеет ничего общего с реальным миром.

Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".

Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы. Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
....
отказаться от выполнения работ, не указанных в ТЗ

http://ru.wikipedia.org/wiki/Техническое_задание