Здравствуйте, Пятачок, Вы писали:
П>Я: П>Это все слова. Весь, я повторяю АБСОЛЮТНО ВЕСЬ функционал должен быть отражен в ТЗ. Как раз во избежании таких вот ситуаций
П>Он: П>Это невозможно.
П>Он: П>Это иллюзия.
П>Он: П>Он не может быть весь отражен в ТЗ, которое пишется один раз до начала работ.
П>Он: П>Многие скрытые потребности выявляются только в процессе тестовой эксплуатации системы.
П>Он: П>Иначе заказчик, как это и бывает в большинстве случаев, остается неудовлетворенным.
Ты неправильно ведешь разговор. Отвечать надо так:
Ты совершенно прав! Действительно, всего предусмотреть в ТЗ невозможно. Это нормальная ситуация. Действовать будем так: собираем в кучу все новые пожелания по переделки и доделки, составляем и утверждаем документ "Change Requests" (это типа мини-ТЗ), я делаю оценку времени и стоимости и если все всех устраивает, я принимаюсь за работу.
У меня сложилось впечатление, что рейт по проекту где-то $5-$7. Правильно?
> Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, > затраченное на исправление багов программиста. А вот такой разговор с > представителем заказчика сложился у меня. Собственно коменты с моей > стороны излишни. Я просто в ауте.
Похоже, заказчик Вам просто не верит. Где-то Вы прокололись раньше.
Скорее всего, при возникновении проблемы не отписались заказчику, а
закрыли проблему тупо выполнив ТЗ. На человеческом языке это называется
"итальянской забастовкой".
Я не в ауте. ИМХО, заказчик вполне вменяем и не ждет от Вас чуда в виде
безгрешного кода без ошибок, насколько я понял с процитированных Вами
разговора. Почему Вы ожидаете, что заказчик будет безгрешен и напишет
ТЗ, которое закрывает все, что только можно? Для невозникновения
подобных проблем в будущем: при возникновении хоть малейших подозрений,
что Вы делаете что-то не то, вне зависимости от ТЗ, задавайте вопросы
заказчику до тех пор, пока не поймете, почему именно так. Кстати, в ходе
подобных разговоров, зачастую, выясняется, что делать можно/нужно
намного проще. Не бойтесь и не жадничайте -- снижайте цену проекта. Это
окупается очень быстро.
Теперь по текущей ситуации. Что я бы сделал. Вам стоит откатиться назад
и выяснить, что же на самом деле произошло. "Вот в этом, конкретном,
месте мы неправильно поняли друг друга. Я протормозил, вы прошлепали."
Признать свою ошибку, заставить заказчика признать свою. Разделить
ответственность (например снизить рейт вдвое) и исправить.
И еще. Ваше имя дороже этой доработки. Просто помните об этом. Даже если
зашли в тупик, выполните работу и только после этого посылайте заказчика.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Практика работы моей конторы показывает, что прописывание деталей в ТЗ, договоры доработки и пр. — это не работает, а только съедает время и нервы.
Это объясняется очень просто: почасовая оплата вместо результата работает только в двух местах:
1. Две крупные организации, одна наняла другую, два друга пожали руки, — есть профсоюзы, эристы и прочий народ, который может наехать. Контракт подписан на годы, при этом оценивались личные отношения, общая стоимость, репутация конторы, и о каждом конкретном отработанном часе никто не заморачивается — оплачиваются тысячи часов в месяц, и если что не так, даются обещания всё исправить. а если начинаются ругачки — в 40% случаев это конец совместному бизнесу;
2. Всякие тренеры, учителя и психологи. Они как-то хитрожопо выбили себе такое право ... тёмная история. Но тут деньги из рук в руки и, опять же, если пошла ругачка — конец отношениям.
(ну может еще есть примеры ... глубоко я над этим не думал)
Все эти договора с пунктами оплаты, этапами и человеко/часами за n рублей — всё это слизано с больших договоров и больших компаний. Каюсь, сам наступал на эти грабли неоднократно. Так можно работать, но это совершенно непродуктивно. Никакого толкового бизнеса.
Так вот, в остальном бизнесе принято брать деньги за результат. Очень хороший пример — доставка грузов. В каждой отдельной достаке может возникнуть много проблем — сломался грузовик на дороге, таможня стрельнула лишнюю штуку баксов, долго искали адрес и т.д. Как раз, чтобы об этом не болела голова и нанимают компанию по доставке. Она гарантирует, что вот за такую финсированную цену ты свою бандероль получишь. И это уже её обязанность сделать так, чтобы на всех доставках она поимела прибыль. Т.е. где-то будет убыток, где-то прибыль. В целом — прибыль.
Что ты подумаешь, если к тебе привезут заказ на 2 дня позже и скажут, что вот вы тут нам не сказали, как сложно к вам добираться, я тут еще 2 раза за маршрутку платил — давайте доплачивайте. Или если позвонят и скажут, что вот книжка ваша с Озона ... она как-то не так была упакована и там таможня, то да сё — плати. Оба варианта можно себе представить и в жизни, но такие компании-неудачники долго на рынке не задержатся. Второй раз ты туда звонить не станешь.
Потому что бизнес — это умение продавать одно и то же со всё более низкой себестоимостью по всё той же цене.
Кстати, шоколадку поэтому запросто могут и поменять.
То, что делает транспортная компания называется управлением рисками перевозки. Она правильно считает цену, она строит своих сотрудников. Управление такими рисками — задача поставщика, а не покупателя.
Какой отсюда совет для софтверной индустрии, если ты фрилансер или маленькая компания. Так же как ты не берешь с заказчика денег за свою саморекламу, за сертификаты и прочее, ты должен стараться максимально решить за него все его проблемы и сделать так, как будто этих проблем нет. Конечно, это должно быть заложено в оплату. Ты должен прекрасно понимать, что ТЗ и стоимость проекта — это не реальные вещи — это мифические штуки, определенный ритуал, из которого нужно вытянуть максимум полезного. Максимум полезного такой: в ТЗ нужно описать функциональные требования к софту, а не конкретику. В договоре нужно прописать условия оплаты, условия выплаты денег до срока по личной договоренности и условия расставания (плохого или хорошего).
То, что ТЗ — это не система, а сумма взята с потолка — все прекрасно понимают. Это можно прямо говорить заказчику. Как определять цену? Она должна превышать кажущююся первоначально стоимость исходя из мифических трудозатрат на некоторый процент типа 30 или 50. Закладывайся так, чтобы даже в самом ужасном случае ты ничего не потерял. Ну или.. 10 рублей там. Имеется в виду ужасный проект, ужасный заказчик, но не твоя ужасно сделаная работа, конечно. Реально-то договоренность идет о рыночной цене, у заказчика есть свое представление о стоимости, и тут важна бизнес-схватка. нужно знать цены на рынке, знать что там реально за эти деньги идет и т.д. чтобы иметь внутреннюю уверенность, т.к. всё равно все эти рыночные цены и обещания — по большому счету пока враньё. Только упорный труд и деловая этика могут сделать из этого вранья что-то удовлетворительное для обоих.
Поэтому если у заказчика в голове есть цифра $10000, допустим, и он за нее железно держится, то нужно просто оценить — хочешь ли ты делать еще один геморный проект за такую сумму + получить еще референс, т.е. еще одного довольного заказчика (референсы, которые просто "сделаны" — их можно просто придумать и вписать в портфолию. важен именно довольный заказчик, которого можно пригласить на встречу, попросить прорекламировать себя и т.д.). А на заявления типа "вот тут мы упростили задачу, это снимает 3 дня, значит уже не $5000, а $4500 — верно?" нужно честно отвечать, что все эти дни сейчас — полная ерунда, всё на глаз, что это ваше упрощение ... крохоборство, ничего щас оценить нельзя, а для снижения стоимости нужно не по сусекам скрести, а, например, предоплату сделать не 50%, а 75 — вот, типа, разговор не мальчика, но мужа.
Нужно чётко запомнить две мантры и транслировать их на переговорах:
1. Я решу за вас все ваши проблемы, все непонятки по ходу проекта будут прояснены, и вы будете полностью удовлетворены результатом за заранее оговоренную цену. Я ручаюсь за это своим опытом и соображалкой в теме;
2. Я делаю это ради денег, это бизнес, поэтому вопрос денег очень важен, и без денег ничего двигаться не будет. Это не означает шантаж, это просьба о платежной дисциплине.
Уверяю, заказчик в подавляющем числе случаев не жадничает, а беспокоится о результате и боится попасть на кидалово. Если контора затевает IT проект, то его стоимость — это не 50% её доходов уж точно. Дай бог 1%. А для тебя это все деньги, что есть и будут. Именно это вызывает в тебе обиду на заказчика, но заказчик, подписывая договора и т.д. не хочет иметь дело с обиженным работником — ему нужен бизнесмен, который решит их проблемы, вытерет все сопли, разгонит привидения метлой и т.д.
Здравствуйте, Пятачок, Вы писали:
П>Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны оплачиваться отдельно и после того как будет оплачено основное ТЗ? У меня уже слов не хватает.
Так, оплаты не было ?
Ничего Вы никому не докажете.
Обозначьте свою позицию — и забудьте.
Не злите себя и других
Лучше давайте координаты заказчика — сюда,
чтоб другие не нарвались
Чтобы не было такого разговора надо пользоваться методикой XP. RUP и прочие MSF себя не оправдывают — особенно для небольших команд.
А при XP — такие разговоры в принципе не возможны.
Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
Он: по поводу "работает криво" я тебе уже писал и приводил примеры как работает в MS Outlook. Боюсь, "криво" в данном случае довольно точная характеристика.
Я:
все такие вопросы описываются в ТЗ. То, что описано в ТЗ, сейчас выполнено в полном объеме. То, что это должно работать как Аутлук — это вы придумали сами. Я уже и так иду на уступки, выполняя требования, о которых не было в ТЗ ни слова
Он:
О том, что ТЗ опичсывает все требования к системе никто не говорил. ТЗ — лишь основа для понимания требовангия к системе. О дальнейших доработках и итеративности процесса мы говорили сразу.
Я:
ого, а вот это уже новость. Ты думаешь для чего вообще пишут ТЗ?? ТЗ для того и пишется чтобы избежать различий в понимании таких вещей между заказчиком и исполнителем
Я: >О дальнейших доработках и итеративности процесса мы говорили сразу
Да, и все они должны быть в рамках ТЗ
Он:
Это в теории.
Я:
это практика. Заказчик может хотеть чего угодно. Это не значит что я должен делать все что ему тольно не захочется
Он:
Такой процесс обречен на создание неуклюжих систем по окончании.
Он:
Практика — это то, что большинство систем кривые и плохо удовлетворяют потребность заказчика.
Я:
Это все слова. Весь, я повторяю АБСОЛЮТНО ВЕСЬ функционал должен быть отражен в ТЗ. Как раз во избежании таких вот ситуаций
Он:
Это невозможно.
Он:
Это иллюзия.
Он:
Он не может быть весь отражен в ТЗ, которое пишется один раз до начала работ.
Он:
Многие скрытые потребности выявляются только в процессе тестовой эксплуатации системы.
Он:
Иначе заказчик, как это и бывает в большинстве случаев, остается неудовлетворенным.
Он:
Что мы и видим в нашем случае.
Он:
Поэтому и сроки тянутся...
Я:
ты прикалываешься чтоли? ты правда думаешь что исполнитель обязан делать все вещи, которые потом напридумывает заказчик? Все, что вне ТЗ — на практике оплачивается отдельно. Но в данном случае я и иду на уступки, выполняя все это
Он:
На практике программные системы не удовлетворяют заказчика. Они не помогают ему делать его работу. Но они отлично отражают требования ТЗ.
Я:
на самом деле я ну прям в шоке. Ты представь ситуацию. Продавец продает шоколадку. Покупатель покупает, но через некоторое время приходит обратно, говоря при этом "вы знаете, мне она не понравилась, я-то хотел бублик, дайте мне еще и бублик"
Он:
Нельзя говорить об уступках в случае, когда регламент не определен.
Он:
Это не "коробочная" продукция — в этом все отличие.
Он:
Это главное отличие софта.
Я:
короче разговор неконструктивен. Давай лучше дождемся комментариев от заказчика
Он:
Это фундаментальное различие.
Он:
Я просто объясняю тебе отличие программного продукта от "бублика".
Я:
я уже сказал то, что думаю по этому поводу. Когда заказчик даст комментарии?
Он:
Я полагаю что сегодня. Если сроки сместятся, я сообщю об этом тебе сегодня.
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
Это решается довольно простым путем. Заранее оговариваются ТЗ и условия приемки. Кроме того, поскольку действительно в ТЗ все не предусмотришь, заранее можно договориться о том, что заказчик получает N часов возни с его проблемами. Все, что сверх того оплачивается либо по почасовой системе, либо составляется новый ТЗ на изменения, и они проводятся, как отдельный проект с фиксированной оплатой.
P.S. Мне приходилось иметь дело с иностранным заказчиком, который пытался повесить на меня то, что поверх моей библиотеки евонные криворукие мальчики не могли запустить свою софтину. Причем ежу было понятно, что проблема на их стороне (библиотека обеспечивала транспорт данных, а у них была проблема с тем, что с этими данными происходит уже потом, после того, как они доехали). Я им некоторое время помогал, но стало очевидно, что если продолжать так дальше, я им забесплатно сделаю весь проект. Помогло только послать заказчика на ..й со словами, что если не хочет, пусть не пользуется, я без него найду, кому эту софтину продать. Минут через 5 позвонил начальник заказчика, и мы обо всем договорились.
Однако российский заказчик в этом плане хуже — он в итоге и не заплатит, и использовать будет.
Вопрос тут не о том, удовлетворяет ли это его потребности, а в том, _о чем вы договаривались_. Если договоренное выполнено — а это то, что в ТЗ — деньги на бочку. О доделке "как в Аутлуке" можно разговаривать отдельно.
Здравствуйте, Дм.Григорьев, Вы писали:
Pzz>>2. Может ли он это использовать, не оплатив Pzz>>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
ДГ>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать. А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...
Здравствуйте, Пятачок, Вы писали:
П>Вот самое обидное, что я уже все сделал, что они там еще хотят — не особо понятно, а денег мне пока так и не заплатили. И боюсь что если начну препираться, то все дойдет до того, что они оставят и деньги и программу себе. В программе может еще с остались недоделки, но и с ними можно успешно работать.
Если до такого дойдет, намекните, что сольете саму программу и идею в Интернет. Обычно отрезвляет, если программа более-менее значимая.
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
Напоминает анекдот о негре, который стал унитазом в женском туалете — всё строго по ТЗ, но результат совсем не тот, который ожидался заказчиком. Расскажите этот анекдот заказчику и объясните, что должна быть описана каждая мелочь. Спрашивайте его сейчас и в будующем (в процессе доработки программы) обо всём, что может быть понято неоднозначно, а так-же, составьте договор, который будет описывать, как должны вносится изменения и дополнения к ТЗ.
Следующим заказчикам объясните это заранее. Всё тщательно обговаривайте и совместно работайте над ТЗ ещё до того, как будут написана первая строка программы. Это сильно облегчит жизнь.
Hello Пятачок,
> Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны > оплачиваться отдельно и после того как будет оплачено основное ТЗ? У > меня уже слов не хватает. >
напиши что-нибудь вроде "А если у меня после завершения работ по ТЗ вдруг
личные деньги закончаться, и я к вам приду, вы меня покормите ?"
Здравствуйте, Она На Нас Ий, Вы писали:
ОНН>Здравствуйте, Pzz, Вы писали:
Pzz>>Это решается довольно простым путем.
ОНН>Думаю, что не просто.
Тут есть 2 простых вопроса:
1. Нужно ли заказчику то, что вы для него понаделали
2. Может ли он это использовать, не оплатив
2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
Здравствуйте, AleksandrN, Вы писали:
AN>Напоминает анекдот о негре, который стал унитазом в женском туалете — всё строго по ТЗ, но результат совсем не тот, который ожидался заказчиком. Расскажите этот анекдот заказчику и объясните, что должна быть описана каждая мелочь. Спрашивайте его сейчас и в будующем (в процессе доработки программы) обо всём, что может быть понято неоднозначно, а так-же, составьте договор, который будет описывать, как должны вносится изменения и дополнения к ТЗ.
AN>Следующим заказчикам объясните это заранее. Всё тщательно обговаривайте и совместно работайте над ТЗ ещё до того, как будут написана первая строка программы. Это сильно облегчит жизнь.
Сильно усложнит жизнь. Обоим. В лучшем случае удастся стрясти денег с заказчика и ничего [полезного] не сделать. В худшем — просто ничего [полезного] не сделать.
В этой ситуации я полностью на стороне заказчика. Его цель — максимально полно решить свою бизнес-задачу при помощи написанной программы. При этом получить решение в ожидаемые сроки и уложиться в бюджет. Все остальное его не касается и не должно касаться.
ТЗ — бумажка для прикрытия задницы в случае провала проекта. Она является устаревшей уже на момент написания. Разработка точного и всеобъемлющего ТЗ, а также поддержка его в актуальном состоянии, может занять больше времени, чем написание программы.
В реальном мире заказчик имеет права:
— получить общий план работ и узнать, что может быть сделано, когда и за какие деньги.
— получать максимум выгоды из работы программистов.
— по заданным тестам регулярно контролировать ход выполнения проекта на работающей версии системы.
— менять свои решения, заменять одно функциональное свойство системы другим согласно меняющимся обстоятельствам.
— своевременно получать информацию о неожиданных изменениях в ходе работ, что позволяет ему вовремя уменьшить общий объем задач и сохранить первоначальные сроки поставки системы.
— прекратить проект в любое время и получить при этом работающую версию системы, разработка функциональности которой была оплачена на текущий день.
Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.
Правила форума нарушены.
— оверквотинг
Правила можно найти в разделе FAQ данного форума и\или ресурса.
Нарушение правил может повлечь за собой санкции, описанные там же — модератор
A>Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.
извините, но написанное выше не имеет ничего общего с реальным миром.
Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы. Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.
Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
....
отказаться от выполнения работ, не указанных в ТЗ
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
М-дааа... Вот против таких бесстыжих уродов и существуют сервисы типа rentacoder.com и weblancer.net, с резервированием предоплаты и арбитражом. Очень действенная мера, между прочим.
по стилю разговора представитель на бота похож
в целом конечно нельзя всего предусмотреть в ТЗ, но Use case системы определить на уровне ТЗ можно и если заказчик хочет бесплатно их добавлять, то тут ему надо объяснять что он неправ
Как бы ты вежливо объяснил ему, что доработки вне ТЗ должны оплачиваться отдельно и после того как будет оплачено основное ТЗ? У меня уже слов не хватает.
1. Не оговорен статус ТЗ и факт, что все последующие доработки, не связанные с исправлением ошибок в рамках ТЗ, делаются за доп. плату. Именно упор на ПЛАТНУЮ дальнейшую доработку и снял бы все вопросы, с одной стороны — что вы это будете делать (развивать систему) и не бросите заказчика, а с другой — это будет делаться за доп.денежку. А как договор подписывался? Если совсем непонятно что и как делать — поэтапно с возможностью внесения изменений в след. этап, но до тех пор, пока тот не начал выполняться.
2. По-моему этот представитель лоханулся на этапе создания ТЗ (в силу своей некомпетености, возможно) и теперь по-еврейски (сорру, если кого нечаянно обидел-к нац.отношение не имеет) пытается выйти сухим из воды, конечно же, за счет исполнителя и очерняя исполнителя в глазах своего руководства.
Что делать:
1. Найти в компетентных источниках определение ТЗ как документа, чтоб не было двоякого толкования.
2. Прекратить общение с этим представителем, выйти на основного заказчика, объяснить ситуацию и примерами из его же бизнеса, но без эмоций и фени, показать трудозатраты и в дальнейшем работать с ним напрямую. Таки, что-то переделаете забезплатно, точнее — в оплату за науку.
Здравствуйте, Pzz, Вы писали:
Pzz>Это решается довольно простым путем.
Думаю, что не просто.
Даже на RAC,
где существует арбитраж.
Никогда не были в арбитраже?
Это у них длится месяцами
Кроме того,
покупатели все под никами.
И открыть новый счёт для покупателя —
очень просто.
А, платёж сделать через кого-то другого
или анонимно.
Как правило,
ТЗ там такие,
что их нужно дорабатывать уже в процессе работы.
Соответственно, рассчитывать
на продление срока.
Если покупатель не продлевает срок,
или ты договариваешься о 5 днях,
а он тебе фактически даёт 1 день,
или канцелирует его в середине проекта,
то кодер ничего в этом случае сделать уже не может.
По всем правилам,
если результат не передан до дедлайна,
то по правилам Покупатель имеет право вернуть себе платеж.
У Покупателя все нити в руках избежать платежа в рамках всех правил
(недоспецифицировать, не продлить, продлить, но на недостаточный срок).
Если Покупатель недобросовестный,
то от кидалово никак не увернуться.
Надежда только на добросовестность Покупателя.
Что тоже неочевидно — фрилансеров ищут далеко
не от доброты, душевной щедрости или большого ума с интеллектом.
Что я делаю?
Я изучаю проекты
и заявляюсь только по проектам,
технологии которых часто повторяются.
Есть и задачи очень похожие
Т.е., если мне не заплатили,
то я знаю,
что я заготовки и опыт всё равно смогу ещё использовать,
если не продать готовые
Здравствуйте, Pzz, Вы писали:
Pzz>2. Может ли он это использовать, не оплатив Pzz>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Здравствуйте, Pzz, Вы писали:
ДГ>>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Pzz>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать.
Ну, во фрилансе просто масштабы не те. Там о серьёзных компаниях речи не идёт. Как правило.
Pzz>А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...
Зато есть фактор жадности. При выборе между "заплатить 80% и получить шиш в масле" и "заплатить-таки 100% и получить заказанное" выбирают обычно второе. Хотя лично у меня гораздо чаще получалось прямо наоборот: честно оплачивают и проваливаются сквозь землю. За последнюю пару лет в портфолио не добавилось ни одной серьёзной ссылки, на выброс работаю.
Здравствуйте, Дм.Григорьев, Вы писали:
Pzz>>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать.
ДГ>Ну, во фрилансе просто масштабы не те. Там о серьёзных компаниях речи не идёт. Как правило.
Да, поэтому у фрилансеров покупают с исходниками, а у мелкософта можно и бинариями взять. Потому что мелкософт вряд ли завтра изчеснет, в отличии от.
Здравствуйте, Пятачок, Вы писали:
П>Некоторые тут возмущались тем, что заказчик не хочет оплачивать время, затраченное на исправление багов программиста. А вот такой разговор с представителем заказчика сложился у меня. Собственно коменты с моей стороны излишни. Я просто в ауте.
я так понимаю, ты ждешь что мы тоже будем "в ауте"? Тогда намекни хоть — как ты с аутлуком разошелся?
Вот самое обидное, что я уже все сделал, что они там еще хотят — не особо понятно, а денег мне пока так и не заплатили. И боюсь что если начну препираться, то все дойдет до того, что они оставят и деньги и программу себе. В программе может еще с остались недоделки, но и с ними можно успешно работать.
Еще поражает отношение заказчика — типа вот мы тут у тебя баги нашли, ай-ай-ай, как же так, пишешь и с ошибками. Боже мой, судя по всему они вообще там не имеют представления о нормальном процессе программописания
Здравствуйте, aik, Вы писали:
aik>я так понимаю, ты ждешь что мы тоже будем "в ауте"?
Да не, ничего не жду, просто захотелось с кем-то поделиться, крик души можно сказать.
>Тогда намекни хоть — как ты с аутлуком разошелся?
С аутлуком я сам не до конца понимаю чего они хотят. В понедельник заказчик даст коменты, тогда станет ясно. Сейчас есть система оповещения, которая раз в пять минут пробегается по значениям из базы и если время какого-то действия пришло, то показывает оповещение. "Как в аутлуке" — я понял что им нужно чтобы сообщение показывалось сразу же, а не раз в 5 мин.
А что собственно удивляет то? Конечно все предусмотреть нельзя в ТЗ. В 90% случаев это именно так и есть.
Другое дело, что это нужно СРАЗУ донести до заказчика, и строить рабочий процесс в соответсвии с этим фактом. Т.е. чтото типа — ваши желания, ради бога, за ваши деньги что угодно. Т.е. нету фенечки в тз, прикидываете стоимость изходя из вашего нормочаса, и пожалуйста, прайс заказчику — фенечка такая то, стокота часов, стоит столькото.
Здравствуйте, Пятачок, Вы писали:
П>И боюсь что если начну препираться, то все дойдет до того, что они оставят и деньги и программу себе.
Правильно боитесь.
Если сразу не договорились,
то лучше помалкивайте теперь
Сделайте кое-что,
а по ходу дела ненавязчиво дайте понять,
что у Вас телефон и интернет за неуплату отключают
Здравствуйте, Пятачок, Вы писали:
П>"Как в аутлуке" — я понял что им нужно чтобы сообщение показывалось сразу же, а не раз в 5 мин.
В аутлуке
(если я правильно понимаю, что речь идёт о MS Outlook,
а не о каком-то из ваших методов или таблиц)
сообщение показывается не сразу,
а в соответствии с периодом,
выставляемым в настройках.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Pzz, Вы писали:
Pzz>>2. Может ли он это использовать, не оплатив Pzz>>2-й вопрос очень важный. Если может (как, например, в России), то особо давить нечем. Надо либо работать только с теми, кому доверяешь, либо не давать исходников до хотя бы частичной оплаты.
ДГ>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Ну дальше находят второго разработчика, которому вешают сказку про нехорошнго разработчика (сказка м.б. очень правдоподобна), чтоб он нашел ошибку и исправил. Тот без задней мысли снимает все блокировки и получает за работу ту же фигу...
Здравствуйте, Pzz, Вы писали:
ДГ>>Плюс внедрять в свои проги блокировку по дате (демо-версия) и обфускатор сверху вешать. Это если без посредника.
Pzz>Только полный урод будет довольствоваться софтом без исходников и без серьезной компании, которая готова его поддерживать. А против полных уродов ничем не защитишься, в т.ч. и блокировками. На то они и полные уроды...
Лично я стараюсь отдавать исходники только после полной оплаты. До этого момента поставляются только бинарники.
Здравствуйте, Пятачок, Вы писали:
П>Вот самое обидное, что я уже все сделал, что они там еще хотят — не особо понятно, а денег мне пока так и не заплатили. И боюсь что если начну препираться, то все дойдет до того, что они оставят и деньги и программу себе. В программе может еще с остались недоделки, но и с ними можно успешно работать.
Ну в общем-то вы сами виноваты. Лоханулись, притом не единожды.
1. Перед стартом проекта надо довести до заказчика план работ и смету. Оговорить, что все дополнительные работы вы с готовностью выполните, но за дополнительную оплату и желательно в отдельной фазе проекта, после завершения и проплаты основных работ. Не согласны? До свидания.
2. Стоило оговорить майлстоны. На каждом из которых вы демонстрируете результаты, а заказчик выполняет частичную оплату. Такой подход минимизирует риски кидалова, ну или по крайней мере минимизирует ущерб от кидалова. Заказчик тянет резину с оплатой майлстона? Уведомляете его о приостановке работ.
3. Не стоит отдавать исходники программы заказчику до финальной оплаты. И подсадить "жучков", сделав программу триальной, тоже можно.
П>Еще поражает отношение заказчика — типа вот мы тут у тебя баги нашли, ай-ай-ай, как же так, пишешь и с ошибками. Боже мой, судя по всему они вообще там не имеют представления о нормальном процессе программописания
Ну дак если они не имеют предстваления, то кто им объяснит? Надо вежливо и с достоинством рассказать, что писать программы совсем без ошибок еще никому не удавалось. Вы понимаете озабоченность заказчика и готовы усилить контроль качества, добавив в проект фазу тестирования сборок или даже введя в проект тестера. Заказчик готов оплачивать эти дополнительные услуги?
И еще: твердолобость и умение встать в позицию — очень полезные умения в бизнесе. Если заказчик вас начал прогибать как ему хочется, то потом переломить ситуацию очень сложно.
Процесс создания ПО это по сути аренда вас на время, заказчиком, ну типа как трактор для пашки. Если вы отлично справлялись со своими обязанностями, но не уложились в запланированные (и согласовванные с вами для согласования нагрузки) заказчиком сроки, то опять же по аналигии с трактором значит трактарист плохо работад — трактор то тут причем... Вам надо просто радоваться и очень вежливо и корректно, иногда даже без слов... Дать понять заказчику, что если он не будет платить за аренду, то вы на него работать не будите. А если будет, то это его дело, пусть хоть ять раз все от нуля переделывает, любой каприз за ваши деньги.
Здравствуйте, Пятачок, Вы писали:
П>Еще поражает отношение заказчика — типа вот мы тут у тебя баги нашли, ай-ай-ай, как же так, пишешь и с ошибками. Боже мой, судя по всему они вообще там не имеют представления о нормальном процессе программописания
А что тут поражает? Если заказчик оплатил фазу QA, то он вправе расчитывать на полное отсутствие багов (за редчайшим исключением). Если же QA оплачен небыл, то заказчик знает, что QA выполняется его же силами, а фикс багов — в зависимости от контракта.
ИМХО вполне адекватная реакция. Вы же не лабу в школе сдаёте, а комерческий продукт.
Повреждение мозга после ректальной биопсии — редкая штука (с) Хаус
T>извините, но написанное выше не имеет ничего общего с реальным миром.
Как раз наоборот. В реальном мире происходит именно так. А мечта об идеальном заказчике, который четко знает чего хочет и никогда не делает change requests — неосуществимая иддилия, которая загубила много проектов.
T>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
Не надо приводить аналогию со строительством. Переделать дом очень сложно, даже поменять проводку в стене — уже трудность. Аналогичные изменения в программе — это норма жизни, при регулярном рефакторинге и наличии юнит-тестов совершенно не представляют проблемы.
У заказчика есть бизнес-задача, которая не меняется. Программа — это реализация модели бизнес-задачи. Эта модель будет уточняться и развиваться, поэтому требования к программе тоже будут изменяться. Но это всегда разумно. Никто не требует начав писать калькулятор резко переключиться на разработку интернет-браузера.
Заказчик, объясняя чего ему хочется и работая с прототипом программы, сам начинает лучше понимать свою бизнес-задачу и ее внутренние процессы. Какие-то функции, казавшиеся второстепенными, выходят на первый план. У других функций замечается неверная реализация. Поэтому изменения вносятся очень часто. Чем лучше организовано общение с заказчиком, тем больше таких изменений, тем они чаще, и тем проще их реализовывать. При это программа не ломается, а вырастает от простого к сложному.
T>Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы.
Это здорово, если фаза длится одну-две недели. Но таких фаз не бывает в проектах с детально расписанными планами, утвержденными сроками и ТЗ. И на практике получается, что туча времени уходит на проектирование, разработку и тестирование _не_того_. Проект к этому моменту уже слишком закостенел, ведь рефакторингом никто не занимался. Когда заказчик обоснованно просит вернуть программу в колею его бизнес-задачи, на него обижаются и приделывают изменения в виде заплаток.
T> Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.
Заказчик должен участвовать в разработке с первого дня, он должен постоянно пользоваться текущей версией программы, стараясь применять ее для решения реальных задач. В каждый момент он должен знать какие функции имеют высший приоритет — их нужно реализовать в ближайшую итерацию, а какие можно пока отложить — а со временем они вообще отвалятся как ненужные.
T>
T>Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
T>....
T>отказаться от выполнения работ, не указанных в ТЗ
abibok пишет: > T>Представьте, что вас заказчик попросил построить дом на два этажа с > гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы > в случае провала проекта). Вы построили 80% дома, как вы считаете > классно, но тут вы от заказчика узнаете, что он передумал и решил > строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, > подземным гаражом на 100 машин, бассейном во дворе и оранжереей на > крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться > в бюджет". > > Не надо приводить аналогию со строительством. Переделать дом очень > сложно, даже поменять проводку в стене — уже трудность.
Господа, я понимаю что у нас это дикость, но в других странах это в
порядке вещей. Речь идет, конечно, не о таких глобальных перестройках,
но изменение проекта в процессе строительства (например коренное
изменение функционала, как-то переделать офисное здание в торговый
центр) достаточно распространенная практика.
Нужно просто софт писать (дома строить) так, чтобы такие изменения не
были проблемой.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Правила форума нарушены.
— оверквотинг
Правила можно найти в разделе FAQ данного форума и\или ресурса.
Нарушение правил может повлечь за собой санкции, описанные там же — модератор
A>Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.
Все это конечно хорошо, но только не на условиях fixed price. Ради бога, пусть меняет условия, задачи, но заказчик должен четко понимать, что любые отклонения от первоначального плана стоят времени, и, соответственно, денег. Так что браться за проект с нечеткими требованиями на условиях фиксированной цены — самоубийственно. Только почасовая оплата. А тогда пусть фантазия играет как хочет. Любой каприз за ваши деньги.
Здравствуйте, abibok, Вы писали:
T>>извините, но написанное выше не имеет ничего общего с реальным миром.
A>Как раз наоборот. В реальном мире происходит именно так. А мечта об идеальном заказчике, который четко знает чего хочет и никогда не делает change requests — неосуществимая иддилия, которая загубила много проектов.
Я в свою очередь могу сказать, что постоянные изменения в ТЗ без пересмотра цены загубили еще больше проектов, поскольку разработчик не будет работать себе в убыток. Почему он должен оценивать трудоемкость и стоимость работ для одних требований к продукту, а потом когда объем работ меняется он не может изменить оценку? Про идеального заказчика, итеративный процесс разработки с короткими фазами (1 мес) и контроль результата, как раз позволяет избежать проблем обоим сторонам — клиент видит, что получается, и может скорректировать направление разработки, если у него появились новые идеи или он так или иначе решил изменить свои требования, разработчик со своей стороны не оказывается в ситуации, когда после полугода разработки, оказывается, что клиент хотел вовсе не то, что получилось. Опять же повторюсь: на заказчика накладывается большая ответственность по контролю хода разработки, если он все это время лежал на пляже на Мальдивах вместо того, чтобы смотреть progress reports, то получит он в итоге такое видение реализации как себе ее представлял разработчик.
T>>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
A>Не надо приводить аналогию со строительством. Переделать дом очень сложно, даже поменять проводку в стене — уже трудность. Аналогичные изменения в программе — это норма жизни, при регулярном рефакторинге и наличии юнит-тестов совершенно не представляют проблемы.
Нормальная аналогия, изменения в требованиях могут привести к полной переделке программы, начиная с полной переработки архитектуры. Рефакторинг тут не спасает, так как начинает отнимать больше времени чем добавление функциональности. Рефакторинг нужен лишь для повышения качества кода и простоты внесения измений, расширений, но изменения тут совсем другого порядка.
A>У заказчика есть бизнес-задача, которая не меняется. Программа — это реализация модели бизнес-задачи. Эта модель будет уточняться и развиваться, поэтому требования к программе тоже будут изменяться. Но это всегда разумно. Никто не требует начав писать калькулятор резко переключиться на разработку интернет-браузера.
Это разумно, но не разумно делать это за фиксированную стоимость, каждое изменение в программе, если это не bugfix (обычно включается в оценку), должно быть оплачено. Это приучает заказчика думать наперед, прежде чем вносить какие изменения, т.е. более ответственно подходить к выработке требований к продукту, а не придумывать все новые и новые фишки каждую неделю. Если продолжать вашу аналогию про калькулятор, заказчик должен отдавать себе отчет в том, что калькулятор и маткад вещи несколько разного порядка и не могут быть сделаны за одну стоимость, и если он все же хочет маткад, до в его интересах сразу об этом в своих требованиях указать, а не пытаться съэкономить в надежде, что исполнитель все потом доделает.
A>Заказчик, объясняя чего ему хочется и работая с прототипом программы, сам начинает лучше понимать свою бизнес-задачу и ее внутренние процессы. Какие-то функции, казавшиеся второстепенными, выходят на первый план. У других функций замечается неверная реализация. Поэтому изменения вносятся очень часто. Чем лучше организовано общение с заказчиком, тем больше таких изменений, тем они чаще, и тем проще их реализовывать. При это программа не ломается, а вырастает от простого к сложному.
Это должно оплачиваться, т.к. исполнитель, когда он подготавливает оценку, не может предусмотреть все изменения, которые придут в голову клиенту в связи с тем что он наконец начал "лучше понимать свою бизнес-задачу" (откуда это исполнитель об этом-то тогда узнает). В противном случае, исполнителю придется закладывать оценку с существенным запасом (скажем в 10 раз), на случай если все же понадобится не калькулятор, а редактор с формулами.
T>>Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы.
A>Это здорово, если фаза длится одну-две недели. Но таких фаз не бывает в проектах с детально расписанными планами, утвержденными сроками и ТЗ. И на практике получается, что туча времени уходит на проектирование, разработку и тестирование _не_того_. Проект к этому моменту уже слишком закостенел, ведь рефакторингом никто не занимался. Когда заказчик обоснованно просит вернуть программу в колею его бизнес-задачи, на него обижаются и приделывают изменения в виде заплаток.
У меня фаза в проекте длится 1-1.5 месяца, конечно, кроме функциональности, которую надо сделать дальше и которая была вынесена на 2 и 3 фазы, чтобы сократить длительность каждой фазы, есть пожелания и изменения. Все их я переношу на последующие фазы, зато я гарантирую, что первую фазу я сделаю в указанный срок и в рамках выделенного бюджета. За это время, одни пожелания заменятся другими и я уже буду приблизительно знать трудоемкость на новый этап работ, это нормально и не влияет на текущий процесс разработки.
T>> Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.
A>Заказчик должен участвовать в разработке с первого дня, он должен постоянно пользоваться текущей версией программы, стараясь применять ее для решения реальных задач. В каждый момент он должен знать какие функции имеют высший приоритет — их нужно реализовать в ближайшую итерацию, а какие можно пока отложить — а со временем они вообще отвалятся как ненужные.
Вот-вот, с одной стороны исполнитель должен понимать, что требования меняются, со своей стороны заказчик должен отдавать себе отчет, что изменения в требованиях всегда влекут изменения в стоимости и сроках. Когда такое понимание присутствует у обоих сторон, это очень хорошо.
T>>
T>>Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
T>>....
T>>отказаться от выполнения работ, не указанных в ТЗ
T>>http://ru.wikipedia.org/wiki/Техническое_задание
A>Позволяет защититься когда заказчик недоволен сделанным. Позволяет избежать штрафов, но проваленный проект не спасает и заказчик уже не вернется.
A>Мне понравилась аналогия с арендой трактора. Именно так и стоит строить отношения с заказчиком. Не fixed price, а subscription.
Я никогда не выставляю fixed price на проект, если он больше недели-двух. Т.е. скорее у меня разновидность subscription сервиса, с часовым рейтом, но мне не удобно и заказчику полагаю тоже, каждую неделю получать счета на несколько часов, поэтому я готовлю оценку на некоторую законченную функциональность, документацию и пр. сразу на месяц. Все что сверх, выносится в отдельную фазу или оплачивается отдельно, если есть возможность без подвижки сроков сделать некоторую работу.
Здравствуйте, Trean, Вы писали:
T>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
У меня сестра как-то рассказывала, что проектировали они многоэтажную парковку с гаражами. Потом заказчик передумал и пришлось добавлять еще один этаж за счет снижения высоты потолков. Если ты думаешь, что подобное изменение ТЗ было проще, чем некислый рефакторинг софта, то ты сильно заблуждаешься.
Так что проблемы в строительстве схожи, только аналогии у тебя неверные. Разработка программы — это этап проектирования здания в строительстве. А этап строительства — это сборка программы кнопочкой Build. После такой корректировки все становится на свои места и проблемы с заказчиком, ТЗ, сроками и т.п. получаются общими.
давно уже известно что правильная аналогия софтостроению-...
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
?
