Дружище, я писал ТЗ, когда в работал бизнес-аналитиком и ПМ'ом по совместительству в одной маленькой, но очень резвой компании аутсорс-компании, державшей в 2002 году 1-е место на elance.com в категории Web Development. За год я пережевывал этих ТЗ под 100 штук.
Результаты таковы: типовой «проект», скажем, интернет-магазин, не вызывал никаких проблем — есть шаблонная спека на данный тип проектов, добавили/удалили фичу согласно пожеланиям клиента -> клиент аппрувит -> сделали -> расчитались -> успешно забыли. За очень-очень редким исключением, все шло просто на ура.
А когда поехали НЕ типовые проекты — частенько случалась ")|(оппа обыкновенная", потому что ожидания клиента не совпадали с нашими возможностями. Качественно обработанный сейлзом клиент ожидал уровня «All Included Five Stars», но предложить особо было нечего, приходилось разбирать бизнес-модель, клещами вытягивать из клиента money flow, data flow, все его ноу-хау, которые он планировал на проект — и это все только для того, чтобы составить это долбанное ТЗ, которое было кривым до ужаса.
Нельзя сделать качественное ТЗ на проект размером больше 4 недель, особенно, когда у вас нет опыта в прикладной специфике проекта. Это примерно, как ожидать от супер-футболиста отличной игры в хоккей.
Более того, мне посчастливилось пройти путь разработчика по дуге:
— «без ТЗ» ->
— «вот какое-то ТЗ, не знаю, почитай и скажи когда будет готов проект» ->
— «суровые ТЗ (RFP, PR, SRS и прочие страшные слова и документы по 100-300 страниц)» ->
— «XP, Scrum» ->
— «суровые ТЗ, адаптированные под Web 2.0 и современный communication».
Т.е. по сути, я попывал в аджайле годик-два и вернулся в классику разработки: говоря откровенно, меня держат только деньги на этом месте. документация в таком состоянии, что шпиЁн-розведчег без поллитры не разберется что где как и почему.
Мне есть с чем сравнивать и я говорю: четкое ТЗ — это миф. Не ждите проекта, не требующего доработок/изменений — таких не бывает.
Неее, это чувак, ты не так прочитал) Еще раз: любой [очередной] каприз за ваши [очень дополнительные] деньги. «Нет ручек — нет мультиков» (с) фольклор народов СССР.
Клиент не всегда четко знает, что он хочет. Зачастую он знает, что ему надо «примерно вот так», а конкретика становится очевидной только в процессе разработки.
Известно, что дьявол кроется в деталях. Но решение этой проблемы придумано этак лет 10 назад, а вы все еще пишете «чёткие ТЗ», которые статичны, в то время, как работа над проектом — динамика.
Если ТЗ больше 2 страниц — оно гарантированно содержит неточности, допущения, ошибки, заблуждения. Пытаться создать ТЗ на 100% отвечающее требованиям проекта — это бессмысленная трата ресурсов.
Оценка проекта должна быть ПРИМЕРНОЙ. Расчеты по проекту — по факту затрат и качества результатов. Европа последние 5 лет делает Agile, а мы все дрочим на «правильное ТЗ» и засираем траффик жаркими перепалками с нулевым эффектом.
Программирование без кодинга не существует. Кодинг без программирования не имеет смысла. Отсюда вытекает, что кодинг — это часть программирования, и, соответственно, работа творческая.
Ага, иди расскажи про мотивацию продавцу газет в киоске.
Не надо путать фриланс, где работа в основном идет по принципу «любой каприз за ваши деньги», и реально интересные проекты, где «хлебом не корми, дай поработать».
> Теперь понятно откуда береца куча идиотов, которые даже не знают как цикл for работает
Вы действительно хотите поговорить об этом? Скажите, какая функция будет работать эффективнее:
function trim2 (string) {
var l = function (string) {
var i = 0;
for(z = string.length; string.charAt(i) == " " && i < z; i++);
return i;
};
var r = function (string) {
var i;
for(i = string.length; string.charAt(i) == " " && i >= 0; i--);
return i;
};
return string.substring(l(string), r(string));
};
var trim1 = function (str) {
for (var z = str.length, l = 0, r = z-1; ((str.charAt(l) == " ") && l++ < z) || ((str.charAt(r-1) == " ") && r-- > 0); );
return str.substring(l,r);
};
Результаты таковы: типовой «проект», скажем, интернет-магазин, не вызывал никаких проблем — есть шаблонная спека на данный тип проектов, добавили/удалили фичу согласно пожеланиям клиента -> клиент аппрувит -> сделали -> расчитались -> успешно забыли. За очень-очень редким исключением, все шло просто на ура.
А когда поехали НЕ типовые проекты — частенько случалась ")|(оппа обыкновенная", потому что ожидания клиента не совпадали с нашими возможностями. Качественно обработанный сейлзом клиент ожидал уровня «All Included Five Stars», но предложить особо было нечего, приходилось разбирать бизнес-модель, клещами вытягивать из клиента money flow, data flow, все его ноу-хау, которые он планировал на проект — и это все только для того, чтобы составить это долбанное ТЗ, которое было кривым до ужаса.
Нельзя сделать качественное ТЗ на проект размером больше 4 недель, особенно, когда у вас нет опыта в прикладной специфике проекта. Это примерно, как ожидать от супер-футболиста отличной игры в хоккей.
Более того, мне посчастливилось пройти путь разработчика по дуге:
— «без ТЗ» ->
— «вот какое-то ТЗ, не знаю, почитай и скажи когда будет готов проект» ->
— «суровые ТЗ (RFP, PR, SRS и прочие страшные слова и документы по 100-300 страниц)» ->
— «XP, Scrum» ->
— «суровые ТЗ, адаптированные под Web 2.0 и современный communication».
Т.е. по сути, я попывал в аджайле годик-два и вернулся в классику разработки: говоря откровенно, меня держат только деньги на этом месте. документация в таком состоянии, что шпиЁн-розведчег без поллитры не разберется что где как и почему.
Мне есть с чем сравнивать и я говорю: четкое ТЗ — это миф. Не ждите проекта, не требующего доработок/изменений — таких не бывает.
Известно, что дьявол кроется в деталях. Но решение этой проблемы придумано этак лет 10 назад, а вы все еще пишете «чёткие ТЗ», которые статичны, в то время, как работа над проектом — динамика.
Если ТЗ больше 2 страниц — оно гарантированно содержит неточности, допущения, ошибки, заблуждения. Пытаться создать ТЗ на 100% отвечающее требованиям проекта — это бессмысленная трата ресурсов.
Оценка проекта должна быть ПРИМЕРНОЙ. Расчеты по проекту — по факту затрат и качества результатов. Европа последние 5 лет делает Agile, а мы все дрочим на «правильное ТЗ» и засираем траффик жаркими перепалками с нулевым эффектом.
Давайте вернемся к теме школьной программы лет через 15, когда Вы будете не в состоянии взять производную от функции без гугления и википедии.
Не надо путать фриланс, где работа в основном идет по принципу «любой каприз за ваши деньги», и реально интересные проекты, где «хлебом не корми, дай поработать».
Очередной вечный двигатель? оО
Вы действительно хотите поговорить об этом? Скажите, какая функция будет работать эффективнее:
function trim2 (string) {
var l = function (string) {
var i = 0;
for(z = string.length; string.charAt(i) == " " && i < z; i++);
return i;
};
var r = function (string) {
var i;
for(i = string.length; string.charAt(i) == " " && i >= 0; i--);
return i;
};
return string.substring(l(string), r(string));
};
var trim1 = function (str) {
for (var z = str.length, l = 0, r = z-1; ((str.charAt(l) == " ") && l++ < z) || ((str.charAt(r-1) == " ") && r-- > 0); );
return str.substring(l,r);
};
У яваскрипта вообще проблем нет, есть только пожелание добавить в него лисповые макросы.
а вот пхп… как язык программирования, пхп должно умереть… ну или трансформироваться в JS, как наиболее близкий по синтаксису :)
JS давно уже вышел за рамки браузера. Some buzzwords: SSJS, CouchDB, WSO2, Helma, jslibs, nekovm, mod_v8, llv8call.