Комментарии 42
Похоже представители Autodesk еще не спят :-)
Пробные версии надо ставить на виртуальную машину. Кончился пробный период — снёс виртуалку, распаковал из архива чистенькую и намазал снова.
А вообще, ТЗ должно быть, но не должно быть чрезмерно формализованным. Так останется некоторая свобода — правда, для заказчика тоже.
ПерфекционизЪм — штука такая… Я тоже им страдаю иногда. Но, потихоньку привыкаю не увлекаться. Ибо то, что ты готов засунуть бонусом (просто потому, что оно добавляет удобства для юзера, но почти не создаёт геморроя разработчику) — не нужно засовывать. Нужно тонко намекнуть, что это возможно. А, поскольку этого не было в изначальном ТЗ — заказчик может получить это за дополнительную плату :)
А вообще, ТЗ должно быть, но не должно быть чрезмерно формализованным. Так останется некоторая свобода — правда, для заказчика тоже.
ПерфекционизЪм — штука такая… Я тоже им страдаю иногда. Но, потихоньку привыкаю не увлекаться. Ибо то, что ты готов засунуть бонусом (просто потому, что оно добавляет удобства для юзера, но почти не создаёт геморроя разработчику) — не нужно засовывать. Нужно тонко намекнуть, что это возможно. А, поскольку этого не было в изначальном ТЗ — заказчик может получить это за дополнительную плату :)
Желание отбросить формализм и приступить к работе и приводит к отсутствию ТЗ. Честно говоря скрипт для автокада был написан за долго до подписания договора и оплаты аванса, в пылу изучения лиспа и попыток понять, что вообще в нем можно сделать. :)
Ну вот я наелся этого — когда хотелки возникают в процессе. Важно уметь культурно это отсечь, чтоб заказчика не обидеть.
В нашем случае часто хватает сказать «напиши мне на мыло, что ты хочешь». А то бывают такие — сегодня ему сделай, завтра исправь, послезавтра верни — а потом с него хрен денег стрясёшь за работу в однократном размере, не говоря уже о тройном.
А эта фраза рубит ~80% хотелок на корню. Какие остаются — получаются чуть более детализированными: хочу вот это и вот так. И пыл остужает: есть письменный запрос, есть выполненная работа — значит, получишь счёт. Проза жизни, конечно, но желание покушать и прочее никто не отменял. Да и поездки к заказчикам денег стоят, пусть и конторе — но контора деньги не печатает. А жаль :)
В нашем случае часто хватает сказать «напиши мне на мыло, что ты хочешь». А то бывают такие — сегодня ему сделай, завтра исправь, послезавтра верни — а потом с него хрен денег стрясёшь за работу в однократном размере, не говоря уже о тройном.
А эта фраза рубит ~80% хотелок на корню. Какие остаются — получаются чуть более детализированными: хочу вот это и вот так. И пыл остужает: есть письменный запрос, есть выполненная работа — значит, получишь счёт. Проза жизни, конечно, но желание покушать и прочее никто не отменял. Да и поездки к заказчикам денег стоят, пусть и конторе — но контора деньги не печатает. А жаль :)
Тут дело не совсем в ТЗ, нужно было с усложнением задач сразу обсуждать увеличение вознаграждения и вы бы остались довольны этим проектом.
На самом деле лично я от проекта в полном восторге, честное слово. И думаю контора наша тоже не в накладе. Просто это был первый опыт разработки когда все объяснялось буквально на пальцах, передавалось как былины и предания, а результаты передавались со словами «это то что вы ожидаете?».
Отличная авантюра получилась, но только благодаря адекватному заказчику.
Отличная авантюра получилась, но только благодаря адекватному заказчику.
Или ТЗ, или контракт на «аренду команды» за фиксированную стоимость в месяц, и тогда «за ваши деньги любой каприз, любые переделки».
Из моей практике как заказчика так и исполнителя:
Нет ТЗ — нет фикса за весь проект.
Иначе в итоге обе стороны будут недовольны
Остается 2 варианта:
1. Почасовая оплата
2. Оплата по итерациям
Вариант 1 предпочтительней для исполнителя.
Вариант 2 предпочтительней для заказчика.
Лучшим вариантом на мой взгляд является второй с разбивкой по задачам и проставленными сроками по каждой.
Это позволяет заказчику самому формировать пул задач и расставлять приоритеты согласно business value.
Нет ТЗ — нет фикса за весь проект.
Иначе в итоге обе стороны будут недовольны
Остается 2 варианта:
1. Почасовая оплата
2. Оплата по итерациям
Вариант 1 предпочтительней для исполнителя.
Вариант 2 предпочтительней для заказчика.
Лучшим вариантом на мой взгляд является второй с разбивкой по задачам и проставленными сроками по каждой.
Это позволяет заказчику самому формировать пул задач и расставлять приоритеты согласно business value.
Кстати, отличные варианты. Приму на вооружение. Спасибо.
2. Оплата по итерациям
Вариант 2 предпочтительней для заказчика.
Да ничего подобного.
Это оставляет риски, что на середине проекта не получится договориться с исполнителем и проект окажется не завершенным.
Не завершенный проект — это почти всегда выкинутые на ветер деньги без результата.
К сожалению, сам был в такой ситуации, причем на месте исполнителя.
Заказчик описал задачу, я оценил ее и мы договорились о сроках и стоимости.
Когда я ее закончил, оказалось, что это был первый этап, а второй(мелочь по мнению заказчика) — только предстоит.
Вот только оказалось, что задача совершенно за рамками моей специализации(написание драйвера, хотя первоначально задача касалась только компьютерной графики). Я согласился попробовать, но предупредил, что задача для меня новая и я не уверен что справлюсь. Предоплату за вторую часть не брал, естественно. В итоге понял, что за разумные сроки с написанием драйверов такого уровня не разберусь и отказался от исполнения.
Что же имеет заказчик в итоге? Он имеет систему, которая не решает задачи для которых создавалась.
Он в итоге наверняка не удовлетворен сотрудничеством со мной(хотя эта тема никогда не поднималась, но наверняка это так).
Я чувствую себя виноватым, хотя уже год прошел(по факту вины моей нет, я изначально на совершенно другую задачу подписывался).
Кстати, если кто-то шарит в эмуляции мыши(нужно отлавливать нажатие мыши на экране на кнопку и двигать курсор. сложность в том, что само нажатие на кнопку не должно генерировать мышиных событий. это нужно для эмуляции мыши через тач интерфейс) — напишите в личку, я вас сведу с этим заказчиком. Возможно ему задача еще актуальна. А мне груз с плеч.
А как нажатие на кнопку не должно генерировать мышиных событий?
Да ничего подобного.
Это оставляет риски, что на середине проекта не получится договориться с исполнителем и проект окажется не завершенным.
Единственный вариант как убрать этот риск — оплата за весь проект по результату.
Интересна формулировка что должно быть на выходе после второго этапа, когда было непонятно что это драйвер.
Честно говоря вижу раздолбайское отношение с обеих сторон.
Со стороны заказчика не было передано четкое понимание того что нужно после второго этапа, тем более если заказчик считал что это «мелочь», значит понимание уже было
С вашей стороны — не было запросов на это.
По итогу я считаю что это проблема заказчика потому что
1. Если он знает какой нужен результат после первого этапа, то должен был потребовать оценить примерные сроки и стек технологий для результата
2. Если он не знал чего хочет — тут вообще не проблема )
Например мне сейчас пишут прототип игры на юнити. И я четко понимаю что
1. Возможен вариант когда придется переписать на UE4
2. Логику запросто придется поменять
3. Вообще придется отказаться от проекта.
И эти риски я закладываю как заказчик.
Я бы не согласился, что наличие четкого ТЗ уменьшает степень неопределенности и бесполезной работы. ТЗ делает более прочной позицию разработчика в спорных моментах, и дает правовую основу, чтобы брать деньги за дурную работу. Чтобы избежать неопределенности и бесполезной работы, ТЗ должно не столько четко описывать каждый чих в программе, сколько адекватно отражать потребности заказчика. А для появления на свет такого ТЗ нужно либо чтобы у заказчика был проджект-менеджер, который отлично знает предметную область и умеет писать ТЗ, либо чтобы исполнитель сам отлично знал предметную область, и мог бы угадать потребности заказчика. Если этого не будет, то работа по ТЗ будет выглядеть примерно так же, как и без него. «Ой, да, действительно, мы согласовали такой вариант, но мы тогда не учли, что… поэтому давайте внесем изменения в… ».
В моей практике был случай, когда заказчик утвердил ТЗ, в указанный срок получил готовый продукт, и оказалось, что это вообще не то, что он хотел. Просто потому, что какой-то менеджер поставил свою подпись, вообще не читая ТЗ, а во всех остальных инстанциях решили, что предыдущий согласовывающий всё проверил.
В моей практике был случай, когда заказчик утвердил ТЗ, в указанный срок получил готовый продукт, и оказалось, что это вообще не то, что он хотел. Просто потому, что какой-то менеджер поставил свою подпись, вообще не читая ТЗ, а во всех остальных инстанциях решили, что предыдущий согласовывающий всё проверил.
НЛО прилетело и опубликовало эту надпись здесь
если клиент плохо представляет, что получит — он не оценит, что получил от вас больше
Золотые слова. Сторонникам подхода «а давайте напишем универсальный расширяемый код» посвящается.
Мы(сторонники подхода «а давайте напишем универсальный расширяемый код») в первую очередь пишем такой код не для того, чтобы клиент рад был. А для того чтобы потом самим было проще его поддерживать и расширять.
НЛО прилетело и опубликовало эту надпись здесь
В принципе, даже для разовых заказов имеет смысл такой код писать.
Ведь то что пишешь для одного проекта можно потом использовать и в другом.
Ведь то что пишешь для одного проекта можно потом использовать и в другом.
И ни что не заменит радости от ощущения качественно сделанной работы.
Я в разработке уже тыщу лет, работал и на заказ, и для in-house, сделал многие десятки проектов. Делал и по нескольку в одной команде, и в разных. Это предпредисловие :)
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
Ведь то что пишешь для одного проекта можно потом использовать и в другом
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
- Когда ты продаешь решение, которое потом будет частью большого проекта. Пример — CMS.
- Когда ты продаешь проект, который является долгосрочным, и однозначно уверен, что он будет дорабатываться. Если уверен!
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо
У меня наверно процентов 80 кода с минимальными изменениями кочует между проектами. Вплоть до того, что это все оформляется в некий фреймворк, который везде и используется.
Может быть у меня задачи такие(разработка игр)… Хотя я рыпался в совершенно левые области ради развлечения(разработка терминалов, например) и там реюз кода также был на уровне 80%.
Единственное что не поддаются реюзу — это собственно логика самого приложения. Взаимодействие объектов и прочие мелочи.
Но в любом проекте с которыми мне приходилось иметь дело(начиная от мелких тетрисов и заканчивая системами работающими в кластере) — логика это мизер. А вся основная работа делается кодом, который можно использовать много раз.
Наверно, если я буду каждый раз браться за совершенно новую задачу: сегодня игра про колобков, завтра веб сайт интернет магазина, после завтра клиент-банк, после-после завтра система видеонаблюдения — у меня тоже не будет реюза…
Но, собственно, с чего мне дергаться между разными областями, если я специалист в одной и могу эффективно внутри этой области решать задачи, в частности за счет огромной кодовой базы собранной на предыдущих проектах.
В качестве послесловия: в этом году 10 лет как фрилансер.
Но, собственно, с чего мне дергаться между разными областями, если я специалист в одной и могу эффективно внутри этой области решать задачи, в частности за счет огромной кодовой базы собранной на предыдущих проектах.
В качестве послесловия: в этом году 10 лет как фрилансер.
Игры — да. Движок, который используется потом в десятках других игр и бизнес-приложение, каждое из которых суть другая разработка — разные вещи.
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Кстати, Ваши наработки для игр — это частные решения, которые становятся частью большого решения — фреймворка. И его тоже очень условно можно назвать CMS :)
Ну чтобы уж не быть голословным — давайте конкретную задачу, которая не может сгенерировать код приемлемый для использования в другой задаче. Мне как-то не верится, что вообще в природе бывают такие задачи, которые на 100% уникальные. Да даже на 50% в уникальность не могу поверить. Так что буду благодарен за пример.
Вставлю свои пять копеек. Я всегда пытался писать код который можно использовать повторно, старался запроектировать с запасом, но почти никогда не использовал прошлые наработки. Просто потому, что через 2-3 месяца я банально забывал где я это писал и как это нужно использовать.
Ну а то, что мне казалось, что я стал умнее и могу лучше, даже упоминать не стоит.
Хотя написанный в 2005 году велосипед-CMS использовал лет 7, правда в php-код я почти не лазил, собирал из изначально написанных блоков. Но это исключение.
Ну а то, что мне казалось, что я стал умнее и могу лучше, даже упоминать не стоит.
Хотя написанный в 2005 году велосипед-CMS использовал лет 7, правда в php-код я почти не лазил, собирал из изначально написанных блоков. Но это исключение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Плюсы и минусы заказной разработки без ТЗ