Ну инет не всегда нормальный. А звонки в пределах города сейчас дешевы.
Но я например через вайбер общался с девушкой когда в Индонезии жил по полчаса в день. Очень даже вариант.
Да ничего подобного.
Это оставляет риски, что на середине проекта не получится договориться с исполнителем и проект окажется не завершенным.
Единственный вариант как убрать этот риск — оплата за весь проект по результату.
Интересна формулировка что должно быть на выходе после второго этапа, когда было непонятно что это драйвер.
Честно говоря вижу раздолбайское отношение с обеих сторон.
Со стороны заказчика не было передано четкое понимание того что нужно после второго этапа, тем более если заказчик считал что это «мелочь», значит понимание уже было
С вашей стороны — не было запросов на это.
По итогу я считаю что это проблема заказчика потому что
1. Если он знает какой нужен результат после первого этапа, то должен был потребовать оценить примерные сроки и стек технологий для результата
2. Если он не знал чего хочет — тут вообще не проблема )
Например мне сейчас пишут прототип игры на юнити. И я четко понимаю что
1. Возможен вариант когда придется переписать на UE4
2. Логику запросто придется поменять
3. Вообще придется отказаться от проекта.
Нет ТЗ — нет фикса за весь проект.
Иначе в итоге обе стороны будут недовольны
Остается 2 варианта:
1. Почасовая оплата
2. Оплата по итерациям
Вариант 1 предпочтительней для исполнителя.
Вариант 2 предпочтительней для заказчика.
Лучшим вариантом на мой взгляд является второй с разбивкой по задачам и проставленными сроками по каждой.
Это позволяет заказчику самому формировать пул задач и расставлять приоритеты согласно business value.
Но я например через вайбер общался с девушкой когда в Индонезии жил по полчаса в день. Очень даже вариант.
Экономится куча денег. Нужен только трафик, притом что как уже сказали — вайфай есть практически у всех.
Единственный вариант как убрать этот риск — оплата за весь проект по результату.
Интересна формулировка что должно быть на выходе после второго этапа, когда было непонятно что это драйвер.
Честно говоря вижу раздолбайское отношение с обеих сторон.
Со стороны заказчика не было передано четкое понимание того что нужно после второго этапа, тем более если заказчик считал что это «мелочь», значит понимание уже было
С вашей стороны — не было запросов на это.
По итогу я считаю что это проблема заказчика потому что
1. Если он знает какой нужен результат после первого этапа, то должен был потребовать оценить примерные сроки и стек технологий для результата
2. Если он не знал чего хочет — тут вообще не проблема )
Например мне сейчас пишут прототип игры на юнити. И я четко понимаю что
1. Возможен вариант когда придется переписать на UE4
2. Логику запросто придется поменять
3. Вообще придется отказаться от проекта.
И эти риски я закладываю как заказчик.
Agile это в первую очередь выгода для заказчика.
Нет ТЗ — нет фикса за весь проект.
Иначе в итоге обе стороны будут недовольны
Остается 2 варианта:
1. Почасовая оплата
2. Оплата по итерациям
Вариант 1 предпочтительней для исполнителя.
Вариант 2 предпочтительней для заказчика.
Лучшим вариантом на мой взгляд является второй с разбивкой по задачам и проставленными сроками по каждой.
Это позволяет заказчику самому формировать пул задач и расставлять приоритеты согласно business value.
Пока в голову лезет по-максимуму все держать в коде, включая подключение и навешивание абсолютно всего.
Маркетологи блин.
И вообще рассказывать о технологии без примеров использования это как предлагать жениться не показывая невесту
Например тут человек хочет обменять ее на кошерную US версию macfile.ru/21333-%5BСПБ%5D-Обмен-apple-wireless-keyboard-int-a1255-на-us-brit.html
Б) Без описания процесса деплоя в ваш контейнер статья выглядит неполной.