И какой выход?
Сделать клиенту то что он уже не хочет?
Переубеждать что веб 2.0 - "так себе"?
По итогу все равно придеться переделывать, а ТЗ сделать это не позволит.
Странно, проекты по 3-4 месяца, до 7 JAVA программистов + пара дизайнеров у нас успешно реализуют проекты без ТЗ.
Хороший проект-менеджер решает вопросы на лету.
Я так понимаю по ХР никто с заказчиками еще не работал?
В большинстве своём клиент не до конца понимает, что хочет получить в результате разработки.
Жесткое ТЗ создает рамки, из которых ни одна сторона не сможет выйти – ибо договор обязывает…
Изменение ТЗ требует дополнительной работы по описанию изменений и оформлению документов, что при работе с удаленным заказчиком создает трудности.
На данном этапе развития права в области ИТ. Даже отсутствие крупных ляпов будет огромным прорывом=)
Потому как большое количество проектов разрабатываются на основе рукопожатия, то есть устных договоренностей
Может стоит создать тематический блог - юридическое оформление ИТ-деятельности?
Для начала можно будет выложить примеры заключаемых договоров.
Обсудим плюсы и минусы каждого важного пункта.
В результате может создадим стандартный договор, который можно будет собирать как конструктор из нужных пунктов.
Думаю многие хабролюди меня поддержат.
Исходя из:
1. стоимости трафика
2. средней скорости подключения (что не маловажно для видео)
3. количества человек говорящих + знающих язык
4. вероятности монетизации проекта
Сам не разбираюсь в таких играх, но когда видел, как друзья играют, в основном, всё сводится к монотонной прокачке персонажа. Может и ошибаюсь конечно.
И какой выход?
Сделать клиенту то что он уже не хочет?
Переубеждать что веб 2.0 - "так себе"?
По итогу все равно придеться переделывать, а ТЗ сделать это не позволит.
Хороший проект-менеджер решает вопросы на лету.
Может мы по-разному понимаем что такое ТЗ?
Дополнительный функционал или другая работа - дополнительный срок => доп. деньги или же урезаем в другом месте работы.
Получается, что клиент сам решает надо ли ему или нет, то что он предлагает.
Если можно посчитайте, сколько времени уходит на создание ТЗ и насколько конечный продукт соответствует подписанному ТЗ.
Интересные результаты получатся.
Я не отрицаю этап проектирования, но писать ТЗ ИМХО дорогое удовольствие и по времени и по деньгам, а вот полезность его я ставлю под сомнение.
Ведь даже в процессе выполнения работ могут выплыть новые идеи.
Или такое исключено?
В большинстве своём клиент не до конца понимает, что хочет получить в результате разработки.
Жесткое ТЗ создает рамки, из которых ни одна сторона не сможет выйти – ибо договор обязывает…
Изменение ТЗ требует дополнительной работы по описанию изменений и оформлению документов, что при работе с удаленным заказчиком создает трудности.
Как Вы предпочитаете решать такие трудности?
=)
Идея рукотворной капчи вполне жизнеспособна.
Тут какой то картон...
Так слишком скучно.
Например "НЛО и законы" будет и повеселей и тематика видна сразу.
=)
Кому засылать первый документ для обсуждения?
Самому не создать блог.
Потому как большое количество проектов разрабатываются на основе рукопожатия, то есть устных договоренностей
Для начала можно будет выложить примеры заключаемых договоров.
Обсудим плюсы и минусы каждого важного пункта.
В результате может создадим стандартный договор, который можно будет собирать как конструктор из нужных пунктов.
Думаю многие хабролюди меня поддержат.
=)
С правами в США, как обычно - "root" всем полицейским.
Исходя из:
1. стоимости трафика
2. средней скорости подключения (что не маловажно для видео)
3. количества человек говорящих + знающих язык
4. вероятности монетизации проекта
- выбрал бы английский язык.