Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, batu, Вы писали:

B>>А пока не знаешь как делать, лучше не браться. Или разделить работу на этапы. Первый этап назвать "Проектирование".

M>Ситуация обычно такая: есть несколько заманчивых путей, но что получится в результате непонятно. Я могу сказать, что написать решение любым способом будет 90 дней, допустим. А вот будет ли этот способ удовлетворительно работать..?
Могу разве что повторить. Пока не знаешь что и как делать, то не делай. Думай.

Здравствуйте, Mystic, Вы писали:

M>По каждому пункту я могу более-менее точно сказать, сколько мне надо на реализацию. Но непонятно, получится ли в результате движок, который играет в нужную силу, или этого будет недостаточно. Иногда путей решения может быть несколько, и непонятно, какой из них лучше.

А вот как раз для таких случаев советские ГОСТы тысяча-девятьсот-замшелого года предусматривали двухфазную организацию НИОКР: сначала ставится НИР, по результатам которой должно быть понятно, какой из путей решения лучше; на выходе НИР получаем в лучшем случае макет, и — самое главное! — кучу бумаги (отчет по НИР) с выводами об исследованных подходах и о целесообразности и направлении дальнейшей работы. А вот потом ставится уже ОКР, на выходе которой и должен получиться готовый продукт. И эти работы планируются и финансируются отдельно.

Здравствуйте, Sharowarsheg, Вы писали:

S>Понимание "что" надо — обычно есть, хотя бы примерно. Иногда бывает, кстати, и "что" подправляется в середине процесса. А вот "как" может и не оказаться. Бывает, приходится делать что-то, чего никто не делал еще, а то и неизвестно, возможно ли это вообще. Наука всю дорогу в таких условиях работает. Вроде и наработанные приемы есть (не совсем же с чистого листа работаешь), а всё равно, или их не хватает, или сразу не поймешь, как комбинировать.
И я так работаю. Но, сначала исследования, потом идеи, потом проверки идей, и только потом реализация.

Здравствуйте, batu, Вы писали:

B>сначала исследования, потом идеи, потом проверки идей, и только потом реализация.

Ну да, и в этих условиях планированию капут. Скажем, запланировать получение идеи трудно, а запланировать получение идеи, которая пройдет проверку — вообще непонятно как. Может с первого раза повезет, а может и несколько циклов "идея-проверка" нужно будет. Бывает еще забава, когда на моделях работало, а на реальной задаче — нет, потому что модели оказались не совсем хороши. На самом деле планирование в таких случаях всё равно делать приходится, но возникает много вилок "если получится это-то, то одно время, а если то-то, то другое время", и всё равно ошибки большие. Менеджера таким планированием обрадовать нельзя.

Здравствуйте, mangaman, Вы писали:

M>Ого. В 3 дня промахнуться всего? В среднем сколько срок решения самой задачи при такой погрешности?

От недели до 4-х месяцев было. Если задача больше недели — я сугубо для себя делил ее на недельные этапы.
Сейчас маячит задача сроком на год, но тут политический вопрос — убедить руководство все переписать Надеюсь, клиенты дожмут жалобами.

Самое тяжелое тут , это менеджменту принять реальные технические риски на RnD. Все остальное как обычно , выделяем время на изучение , поиск , анализ , прототипирование , тесты и т.п.

В итоге вы уложились в сроки и решили задачу или не уложились и не решили. Оба варианта надо закладывать при планировании и считать риски и деньги.

On 14.07.2013 22:52, batu wrote:

> Не берись за то чего не знаешь. Сначала обучение..
Что тут сложного?
Изучаешь то, что в этой области сделано до тебя, повторяешь, если уже
сделано, если еще не сделано, на основе изученного предполагаешь, что и
как сделать, смотришь получилось или нет, если не получилось,
разбираешься что не получилось и почему, на основе изученного
предполагаешь, что и как сделать, смотришь получилось или нет, если не
получилось и т.д. пока не получится.

On 15.07.2013 12:30, _Obelisk_ wrote:

> 12 лет работаю с такими задачами. Как-то всегда интуитивно умудрялся
> оценивать сроки. Ошибки были лишь +1-3 дня. Причем обычно из-за
> конфликтующих других задач.
Впечатлил про +1-3 дня в R&D.

B>>>А пока не знаешь как делать, лучше не браться. Или разделить работу на этапы. Первый этап назвать "Проектирование".
M>>Ситуация обычно такая: есть несколько заманчивых путей, но что получится в результате непонятно. Я могу сказать, что написать решение любым способом будет 90 дней, допустим. А вот будет ли этот способ удовлетворительно работать..?
B>Могу разве что повторить. Пока не знаешь что и как делать, то не делай. Думай.
Ну так дело в том что процесс думания включен в процесс решения таких "изобретательских" задач. Его нельзя вычленить. И он то и является труднопредсказуемым по времени.
Обычно такие проекты имеют две стадии: стадия прототипирования (Proof-Of-Concept), когда на коленке собирается нечто, что содержит в себе решения тех самых технических проблем (которые зачастую очень далеко от "какую же библиотеку использовать?"). Ну и стадия изготовления конечного продукта, когда уже все известно и тупо садимся и кодим.

Здравствуйте, mangaman, Вы писали:

M>А как быть если у вас почти вся работа что-то напоминающее R&D? Как бы любая ваша задача получается совершенно новой, непредсказуемой и не видно неделю ее делать или год?

А можно пример такой задачи?

Мне как-то трудно представить задачу, которую делай хоть неделю, хоть год — пусть "идет как идет" и никто не спросит за сроки и никто не перестанет платить зарплату Также трудно представить задачу, которая может потребовать года работы и которую нельзя декомпозировать на более мелкие задачи. Поэтому и спрашиваю пример, интересно.

А так — да, бывают задачи типа research, когда оценить время выполнения невозможно. На такие задачи можно выделять определенное время (timebox). По истечению которого принимается решение, что делать дальше.

Здравствуйте, batu, Вы писали:

B>Не берись за то чего не знаешь. Сначала обучение..

Не всегда бывает возможность обсуждения, так же как и не везде agile. А вот время на изучение проблемы нужно выделять.