LVV>>3. Листер и де Марко отмечают, что зависимость от опыта работы была отмечена как раз у юниоров первого года. После 3 лет производительность от опыта не зависит. lpd>Это если под программированием понимать кодирование, без проектирования.
Наши американские друзья так и понимают: программист — это тот, кто работает с кодом.
А кто с кодом не работает — это НЕ программисты.
Аналитики-проектировщики они...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Шапкозакидательство в разработке ПО: хорошо или плохо?
LVV>Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше.
Кому нужна производительность без успешных результатов?
Я лучше найму опытного лентяя но который сделает мне задачу в срок (даже если он половину этого срока провалял дурака), чем джуна который будет изображать бурную деятельность но ничего не сделает.
Re[10]: Шапкозакидательство в разработке ПО: хорошо или плохо
S>Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы.
Лаптев не работает в коммерческих структурах, где нужно уметь считать время и деньги.
S>А вас мне искренне жаль. Я сам раньше был таким.
Если и дальше будешь таким то рано или поздно тебя погонят.
S>Вот то что вы декларируете -- это и есть шапкозакидательство. Вы искренне верите что сможете дать точную оценку. На самом деле это никому не под силу, главное развернуть ситуацию так, чтобы ответственность за неверную оценку была на каждой из сторон.
Если нельзя дать точную оценку — делай декомпозицию задачи до тех пор пока не сможешь дать точную оценку. Конечно погрешность всегда будет но если в интервале [-20%; +20%] то это нормально, до +50% скажем так терпимо если такое происходит не слишком часто.
Re[11]: Шапкозакидательство в разработке ПО: хорошо или плохо
Здравствуйте, turbocode, Вы писали:
S>>Тебе уже много раз выше опытные люди объяснили твою ошибку. Прочитайте хотя бы ответ нашего уважаемого Лаптева, который не первый десяток лет работает в академических кругах, учит людей писать ПО. Это азы. T>Лаптев не работает в коммерческих структурах, где нужно уметь считать время и деньги.
Ему и не нужно -- он на более высоком уровне абстракции -- знает теорию управления проектами. Его ученики уже вполне работают в коммерческих стр-рах.
S>>А вас мне искренне жаль. Я сам раньше был таким. T>Если и дальше будешь таким то рано или поздно тебя погонят.
За что? За то что делаю работу качественно по рыночной цене?
Выгнать за неумение предсказывать -- не разумно. Я могу умножать на 3, как тут советовали. Но тогда никому такие сроки не понравятся. А вот когда уже по факту -- тогда смиряются.
S>>Вот то что вы декларируете -- это и есть шапкозакидательство. Вы искренне верите что сможете дать точную оценку. На самом деле это никому не под силу, главное развернуть ситуацию так, чтобы ответственность за неверную оценку была на каждой из сторон.
T>Если нельзя дать точную оценку — делай декомпозицию задачи до тех пор пока не сможешь дать точную оценку. Конечно погрешность всегда будет но если в интервале [-20%; +20%] то это нормально, до +50% скажем так терпимо если такое происходит не слишком часто.
На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
Если вы можете предвидеть все проблемы на этапе планирования -- накой черт вам наемный труд? Легко станете миллионером и вам никто не нужен.
Re[5]: Шапкозакидательство в разработке ПО: хорошо или плохо?
LVV>>Конкретно: производительность лучших программистов по сравнению с худшими (с точки зрения производительности!) примерно в 10 раз лучше. T>Кому нужна производительность без успешных результатов?
Это — по умолчанию. Неуспешные результаты в этих экспериментах отсутствуют.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[12]: Шапкозакидательство в разработке ПО: хорошо или плохо
S>На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить.
P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта.
Re[13]: Шапкозакидательство в разработке ПО: хорошо или плохо
09.11.2017 15:01, turbocode пишет: > S>На этапе планирования задача видна лишь в общих чертах. В процессе > появляются такие проблемы, о которых вы и помыслить не могли. > > Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна > вам в той степени детализации который соответствует вашему опыту чтобы > оценить. > P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду > своего опыта.
Практически любой проект в ПО занимает всё, отведённое на него время,
всегда есть что по нему поделать (исключения довольно редки). Так что
вопрос "попадания в оценку" по проекту/этапу проекта, размером примерно
в человеко-год хотя бы — это вопрос только о том, а что мы выкинем или
сделаем чуть получше чем "good enough". Тру-синьоры это делают или
какие-либо другие — неважно. Если заказчик с оценкой "на этапе
планирования" согласен, ему будет предоставлено X ресурса, а не "в
точности Y" функционала.
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[13]: Шапкозакидательство в разработке ПО: хорошо или плох
Здравствуйте, turbocode, Вы писали:
S>>На этапе планирования задача видна лишь в общих чертах. В процессе появляются такие проблемы, о которых вы и помыслить не могли.
T>Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить.
Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
Собственно, для некоторых проектов сотни тыс. у.е. на этап планирования -- это не много. Но для низкобюджетных это не подходит -- там сроки нужно назвать сразу и бесплатно, никто не будет платить серьезные деньги за проект/план. Не, ну может $400-500 и заплатят, но настоящий проект/план на эти средства не сделать.
T>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта.
Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
Если чел. работает по найму -- значит мозгов на самостоятельный проект все-таки не хватило.
H>Практически любой проект в ПО занимает всё, отведённое на него время, H>всегда есть что по нему поделать (исключения довольно редки). Так что H>вопрос "попадания в оценку" по проекту/этапу проекта, размером примерно H>в человеко-год хотя бы — это вопрос только о том, а что мы выкинем или H>сделаем чуть получше чем "good enough". Тру-синьоры это делают или H>какие-либо другие — неважно. Если заказчик с оценкой "на этапе H>планирования" согласен, ему будет предоставлено X ресурса, а не "в H>точности Y" функционала.
Обычно оценивают самый минимальный функционал(но расширенный функционал тоже должен быть известен (но делать его не нужно) чтобы изначально правильно заложить архитектуру — чтобы не возникло потом ситуации "архитектура для этого не предназначена — нужно всё переделывать")
Re[14]: Шапкозакидательство в разработке ПО: хорошо или плох
T>>Вы сами ответили на свой же вопрос: делайте так чтобы задача была видна вам в той степени детализации который соответствует вашему опыту чтобы оценить. S>Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
Выходит что у тебя тупо нету опыта.
T>>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта. S>Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
Допустим я оценил бы проект по себе в месяц работы, потом заказчик пришел бы к тебе а ты реально потратил три месяца. Кто виноват? Я или Ты?
Re: Шапкозакидательство в разработке ПО: хорошо или плохо?
Здравствуйте, turbocode, Вы писали:
S>>Тогда стоимость планирования будет сопоставима со стоимостью разработки. И сроки планирования будут достаточно большими.
T>Выходит что у тебя тупо нету опыта.
Тебе уже объясняли -- если задачи не типовые (типа ты каждый день делаешь сайты-визитки с ограниченным набором функционала) -- опыт не поможет.
Как вы объясните это:
Ошибка происходит независимо от того, знает ли индивидуум, что решение аналогичных задач в прошлом потребовало больше времени, чем планировалось
https://ru.wikipedia.org/wiki/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%BF%D0%BB%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
T>>>P.S. Как правило тру-синьоры могут оценить задачу и в общих чертах ввиду своего опыта. S>>Если чел. может спрогнозировать все этапы работы при проектировании -- он не будет заниматься наемным трудом. Нафиг это ему нужно, если он с такой же легкостью сможет составит бизнес-план и замутить бизнес, который будет приносить чистую прибыль, не требуя постоянного участия.
T>Допустим я оценил бы проект по себе в месяц работы, потом заказчик пришел бы к тебе а ты реально потратил три месяца. Кто виноват? Я или Ты?
А если мозг включить?
Задачу можно выполнить по-разному. У меня за 10+ лет работы не было ни одного случая, когда бы условия не расширялись/уточнялись в процессе работы. Задаете вопросы, предлагаете варианты и заказчик отказывается от своих старых идей в пользу новых. А это увеличивает время. Все просто.
