Вопрос. Если РП проимелся с оценкой трудозатрат и они по факту оказались выше, то что с этой проблемой делать? Что делают у вас?

(0) +допустим, задача "Создать отчет" заняла не 5 часов, а 45 часов.

С виду отчет был простенький, а на деле оказалось, что для реализации отчета потребовалось добавлять отдельный разрез учета в конфигурацию.
При этом задача уже сделана.

(0) Это франч? Если да, ничего особо страшного. Будет небольшой убыток, но потом этот функционал можно продать кому-то ещё.

РП можно сделать выговор и лишить премии. )

P.S. Хотя, может там всё не так, и прог до последнего скрывал от РП эту сложность...

(2) а если функционал уникален и продать кому-то еще возможности нет? :)

Ну РП у нас ессессно в роли архитектора в том числе, т.е. оценка трудозатрат была на РП

все просто:

есть
1. Исполнитель
2. РП
3. Директор

дальше среди этих троих расписываем убыток, все втроем пытаются свалить вину на остальных, кто докажет свою правоту тот сам и выйдет чистым (без финансовых потерь)

пример

РП говорит - отчет простой, это 8 часов работы

Исполнитель потратил 36 часов, по любому исполнитель не прав, он знал, что не вписался и должен был по истечении 8 часов доложить руководителю, далее руководитель принимает решение или "делаем дальше даже в убыток" и тут исполнитель не виноват, или "исполнитель не профи" и эту работу делает за 8 часов кто-то другой а исполнитель остается без бабла...

(6) нет, исполнитель сообщил о превышении.

РП принял решение, что делать все равно нужно и сказал делать.

(0)[Что делают у вас?]
по разному
чё спросить то хотел ?

(7) >>>РП принял решение

значит это его ответсвеность, пусть идет к директору и разбирается с ним, если он дорог директору - директор возьмет убытки на себя, если нет вычтет из зп РП

Если исполнитель берет задачу от РП с готовой оценкой и видит, что он по любому не уложится в заданную оценку - возвращает задачу как можно быстрее. Часто возвращать смысла нет, т.к. другому исполнителю не отдадут.

Делает столько, сколько потребуется, на закроют только 8 часов.

Если у РП нет возможности (по любым причинам) указывать в оценке много часов - Исполнитель бунтует и либо его переводят к другому РП и ситуация повторяется. Либо Исполнитель увольняется.

При условии, конечно, что оплата Исполнителю идет на почасовку.
А нет почасовки - нет проблем. Надо только закрыть ВСЕ задачи по Проекту в означенный заранее Срок, не за Часы, а в Срок.

(0) Бывает выше, бывает ниже, бывает что задача не имеет возможности оценки

присоединюсь к вопросу (8)

(0) В каждую работу включены риски на случай ошибки в трудоемкости или необходимости исполнений обязательств по гарантии. Либо в стоимость часа, либо в количество часов. Так что просто минусуем из этого фонда реализовавшиеся риски и работаем дальше.

Пришлось оценивать работы, которые не представлял, как делать.
Ладно, это уже другая история, спасибо за ответы.

(13) С потерей девственности тебя ;-)

(13) почему бы не обратиться к клиенту и объяснить ситуацию?
у меня как правило относились с пониманием и соглашались увеличить сумму

если не соглашаются то следующие оценки нужно будет несколько увеличивать чтобы возместить потери

(15) ты же не знаешь, на какой стоимости часа и на какие суммарные количества часов они выходят

перескок с 5 часов - примерно один день
на 45 часов - неделя+
слишком существенный прокол, тем более, если там под вопросом подвисает весь график работ

я потому и пишу, что разработчика нужно изолировать от заказчика при наличии РП, чтоб сглаживать и закрывать перекосы в графике.

(0) слишком мало информации

(0) Зависит как часто это "РП проимелся" происходит.
Если часто то только или менять РП или менять исполнителя или менять тип задач.

Когда задач много в среднем "проимелся" бывают в обе стороны и вот плюс на минус и дает ноль.

Я на эти каверзные задачи быструю оценку даю от дня до года. Еще ни разу не ошибся.
Чем точнее срок нужен - тем больше времени на анализ надо и за это, внезапно, тоже надо платить.
И соглашусь с (11) есть задачи без возможности оценки. Или копаем или нет.
Речь идет, конечно не о типовых 100 раз решенных задачах, а именно об уникальных случаях.

(21) Вот если проеб после тщательного анализа - это да, косяк.

(22) Что делать: Списать и забыть, ситуация на самом деле случается очень часто, за анализ платить никто особо то и не хочет -> выше риски исполнителя -> Выше цена часа. Она сейчас в МСК во франчах уже к 4 приближается.

(0) Работал кодером у знакомого РП, когда у него своих не хватало ребят.
Если он ошибся в часах, то на моей оплате это никак не сказывалось.

(22) Анализ на некоторых задачах бесполезен ибо для оценки времени надо знать знания исполнителя в части как платформы так и конкретной конфы или предметки.

А если РП работает с некими безликими усредненными суперисполнителями то подобные "проимения" будет стандартом.

(25) Я абсолютно согласен с тем, что некоторые задачи не могут быть оценены точно в принципе.
Свежайший пример - нужно было ускорить выгрузку за 8 часов, в итоге такое г..но нашел - что уже 3ю неделю на нем торчу.
Кто виноват - никто.

(26) И помимо меня на нем еще с нашей стороны и со стороны заказчика люди торчат.
А решения, до сих пор нет.

(0) У нас в 99.9% случаев принимают все часы, какие были потрачены исполнителем на задачу. Все риски на РП. Однако, если такие факапы будут частыми, то с таким исполнителем просто никто не захочет работать в дальнейшем. Будет сидеть без работы на минимальном окладе, а потом уволится.

(1) "гладко было на бумаге"? Про "овраги" нужно сообщать ещё до начала работ. Иначе может получиться не очень хорошая ситуация. Не есть гуд ставить заказчика перед фактом, что вот это оценивалось в 100$, но мы потратили намного больше времени, платите 1000$. Может заказчик и не хотел покупать это отчет за 1к$, а сотка и так была пределом.

+(29) ну в смысле, о превышении оценки по времени нужно сообщать как можно раньше, когда это превышение только показалось на горизонте

В бите спб когда работал, дык там на одном из проектов все задачи, которые меньше 20ч, проходили без согласования

Если задача более 20ч - согласовывалась с заказчиком.

(30) а что происходит с потраченными на задачу трудозатратами, если заказчик отказывается давать средства на задачу?

выставляются заказчику или идут в убыток проекта?

На самом деле моя ошибка вот в чем:

Если оценивать задачи, будучи уставшим, то риск проиметься и недоглядеть возрастает.
Оценкой задач надо заниматься с утра, на свежую голову.
В принципе мою текущую проблему можно было бы предусмотреть, если бы уделить больше времени оценке (было доступно) и с утра, когда голова лучше работает.

Семь раз отмерь, как говорится.

(0)это же очевидно Вася.  Кто ошибся, тот и возмещает ущерб. Либо пусть платит программисту из своего кармана, либо пусть сам делает.

(34) не все так просто, как кажется.

вопрос не про программиста, ему, конечно же, все будет оплачено

вопрос про то, как минимизировать количество таких ситуаций в случае, если доподлинно неизвестно, как делать задачу и сколько ресурсов уйдет

т.е. грубо говоря, проект стартует без полного объема материалов, требуемых для корректной оценки

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

статья бюджета "резерв трудозатрат" выглядит как-то по-детски

(28) // У нас в 99.9% случаев принимают все часы, какие были потрачены исполнителем на задачу

Т.е. ваш РП расплачивается со своим исполнителям согласно так называемой почасовки и при этом "закрывает" исполнителю все часы?

Или перекладывает перерасход почасовки в адрес Заказчика уже постфактум?

Я выше приводил пример из своего опыта - Исполнитель получал всегда столько, сколько назначал РП в своей оценке, но у Исполнителя была возможность принимать задачи с подтверждением, что он согласен с оценкой РП

(35) нужна какая-то предварительная классификация проектов
и принятие выбираемых согласно с ней схем учета времени - измерять абсолютно всё, грубо говоря, одним шаблоном не получится.

Т.е. заведомо длительные проекты наверняка будут содержать большое число отклонений от предварительных оценок

Оценка - это не одна цифра. Это две цифры (нижняя граница и верхняя). У меня редко они менее чем в 4 раза отличаются (Я пессимистически всегда оцениваю, ну и под ключ).

Если плательщик не готов принять тот факт, что оцененная таким образом и выполненная задача может потянуть по верхней границе, то брать в работу такую задачу не кажется разумным.

Далее, проеб в оценке в 10-20% случаев - норма. Если плательщик не готов принять тот факт, что его задача с обозначенной вероятностью может выйти за верхнюю границу оценки, то брать в работу такую задачу также не кажется разумным (при отсутствии иных мотивов так делать - например, с целью привлечения жирного клиента выдержать оценку любой ценой, даже в убыток).

Ну и напоследок - нет ничего проще, чем дать оценку со 100% точностью - для этого надо просто собственно выполнить задачу. Просто это будет стоить столько, сколько собственно сама задача.

(21) Ага, а у заказчика торги и все такое. А тут ты такой "Ну не знаю - как получится". В итоге вариант или тыкаешь пальцем в небо, или вообще не участвуешь в конкурсе.

(24) Т.е. если он сказал 8 часов, а надо 48 - платили за 8?

(43) Видимо с плательщика брали сколько изначально сказано (8), а исполнителю оплачивали по факту (48)

(25) Обычно РП работает с идиотами (можешь сам спросить), а не суперисполнителями :)

(26) На такой задаче (а это задача оптимизации, которая априори тредует огромного количества времени) за 8 часов можно только спецификацию на новое, более быстрое, оборудование составить и выдать рекомендацию к закупке.

(35) надо контролировать работы в процессе, чтобы своевременно реагировать на отклонения. Если своевременно заметить отклонение, то можно либо скорректировать исполнителя. либо согласовать с заказчиком изменение ТЗ и переоценку.
При этом бывает так, что при оценке не был известен какой-то факт или нюанс архитектуры или этого всего тупо не заметили, т.к. это не очевидно. Это бывает. И сроки фактические реально могут отличаеться от плановых и в два, и в десять раз. Само по себе наличие этих отклонений - не проблема. Особенно, если своевременно их замечать и четко по ним отрабатывать управленческие воздействия. Проблема, когда они у кого-то становятся массовым явлением.

Надо общаться с разработчиками каждый день, а не только, когда они задачу сдают

(33) Именно, то, что кажется поначалу адекватной оценкой задачи, надо умножать на 7 :)

Бывает, что исполнитель не знает, как сделать задачу за 8 часов, поэтому он её делает 45

(34) А еще можно сделать так, чтобы задача как бы была решена, но заказчик понял, что это не то, что он хотел - и тогда можно всё превышение в переделывание запихнуть.

(35) Тут довольно просто: по ходу дела концепция будет меняться на таких проектах, так что всё что прошляпил - можно включить в доп. соглашение.

(33) это тебе сейчас так кажется, когда ты всё знаешь. Тогда ты оперировал информацией, которая появилась только сейчас. Точно оценить так, чтобы совпало, можно только простые задачи, которые и в оценке-то не нуждаются. Сложную тоже можно оценить, чтобы совпало, но для этого ее надо процентов на восемьдесят решить.

Ошибки в оценке - это нормально. Абсолютно нормально.

Твоя задача вовремя обнаруживать их и вовремя на них реагировать. Потому, что реагировать, когда уже 48 часов из пяти потрачено, уже поздно и смысла нет реагировать - всё уже случилось

(44) Тогда оплата менялась: если была названа стоимость за 8 часов, а заплатили за 48, то суммы ведь разные получаются.

+ (49) если исполнитель реально за 8 не сделает, то он получает свои 48

(49) Так задача оценивается в нормо-часах. Неважно, сколько неквалифицированному исполнителю потребовалось времени. Важно сколько времени должно было быть затрачено по норме.

(54) нет

Труд должен быть оплачен

(53) Если исполнитель (который во франчах, обычно, ни бельмеса не понимает в автоматизируемых бизнес-процессах, т.к. просто не общается с заказчиком) не сделает за 8 часов - значит он не обладает нужной квалификацией. Ему приходят задания уже в таком разжеванном виде, что по времени оценка довольно точная. Превышение времени становится видно на этапе постановки задачи исполнителю.

(55) С какой стати, если он не умеет пользоваться имеющимися возможностями платформы? Например, стал лабать сложный отчет по месяцам за произвольный период с группировкой в колонках на обычном коде "7.7 стайл" вместо того, чтобы использовать СКД?

(54) А кто придумывает нормы? Сколько по норме может занять отчёт?

(36) РП всегда закрывает часы исполнителю, т.е. исполнитель всегда получит свою зп. Но не всегда эти часы оплачивает заказчик, соответственно, это падает затратами на бюджет РП. А дальше уже возможны нюансы, но это уже другая история) Важно ли то, что конкретно у нас исполнитель никогда не станет крайним.

(35)А никак! невозможно ведь оценить работу не зная ее объема. Здесь нужна хитрость и индивидуальный подход в данном случае. Обозначить примерный диапазон сумм, но сообщить, что точная сумма будет известна после появления всех материалов. И предложить им оценить лишь первый этап задачи или несколько этапов - покуда позволяет предоставленный материал. И работать поэтапно.  Ну вот лично я так делаю. И заказчиков убеждаю в том что невозможно оценить объем работ пока не расписано полностью ТЗ.  Каждая формочка - это n-ное количество часов. И заранее неизвестно во что вообще выльется проект. Может над ним придется пол года работать и хотелки будут всё поступать и поступать.
Просто если заранее подписаться на сроки и сумму, то ловушка захлопнется и придется работать в убыток скорее всего.
Ну это как водителя спросить "за сколько ты сможешь доехать из А в Б через пункт С если известна длина дороги АС, но пока еще неизвестна СБ

Кстати, если уж на то пошло, то программирование в решении большинства задач составляет 25-50%, не больше. Остальное уходит на составление и согласование ТЗ (это тот еще балет, где каждую запятую могут по несколько итераций согласовывать), постановку задачи в понятном для исполнителя виде, тестирование и развертывание. До программиста франча просто не доходят задачи, которые могут по реальной трудоемкости различаться в разы.

(58) Берем квалифицированного специалиста - и измеряем время, за которое он выполнит задачу. А можно просто РП сказал - значит это и есть норма :)

(58) // Сколько по норме может занять отчёт?

В зависимости от выбранной предметной области. И в зависимости от установленных стандартов.

Когда отчет нужно красиво оформить и в шапке, и подвале, а основная часть данных может быть выбрана на СКД...
Если в шапку придется тащить всякую муть и в подвал точно также, а содрать это все в готовом виде неоткуда
- вот и пробуй оценить затраты на этот отчет. Сдирать с готового шаблона - одно время. Собирать с нуля - совсем другое и еще не известно с какой попытки Разработчик выберет оптимальный по трудозатратам способ решения.

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

Возьми для примера уже какой-то готовый отчет, дай ему свою оценку и сравни с чужими оценками.

(60) где же такие заказчики находятся, которые не знают когда исполнитель выполнит задачу, да ещё не знает сколько денег она будет стоить?

(32) а тут уже как договоришься. Если удастся впарить эти часы заказчику, то в доход, если не удастся, то в убыток.  Заказчик может просто встать в позу и заявить, мол какого буя вы мне продаёте этот отчет в 10 раз дороже от изначально оговоренного... И будет прав. Но даже если заказчик согласиться оплатить эти часы, может пострадать репутация, а она куда дороже тех копеек с отчета. В этот раз оплатят, а на следующий проект не возьмут. Вроде бы и своё у заказчика отбили, а вроде и потеряли.

(62) это всё мура. Отчет может быть бюстгалтерским регламентированным, в котором 9000 строк, каждая из которых, - это обороты каких-то конкретных счетов с конкретными отборами и прочими кренделями. В одной строчке тебе надо три счета и отбор по массиву предопределенных элементов, а в другой - десяток счетом и всякие ЕСЛИТОИНАЧЕКОГДАТОКГДАНИКОГДА. Это без вариантов нормировать. ДенисЧ говорит о том, что нормативов каких-то общих нет, не будет и быть не может. Не существует такой линейки, к которой 1сник может приложить мпх и получить количество часов, которые потребуются на некий заданный отчет.

(65) не понял твоего ответа

(66) "нормативов каких-то общих нет, не будет и быть не может" - здесь же всё понятно?

(65) Ты когда распишешь задачу для конечного исполнителя - очень точно сможешь посчитать его трудоемкость. Там же элементарные операции получаются уже. А приблизительно сможешь прикинуть на этапе составления ТЗ, где все это будет прописано - такж просуммировав хотелки. А если ты не можешь - значит не дорос ты еще до РП.

(65) // ДенисЧ говорит о том, что нормативов каких-то общих нет, не будет и быть не может.

Он просто задал вопрос в (58)
// А кто придумывает нормы? Сколько по норме может занять отчёт?

Я не вижу в его вопросе утверждения, на которое не нужно отвечать

(65) ну почему никогда? Я вижу возможность формализации. Говорю с собственного опыта. Я разработал нормы трудоемкости при выполнении работ при создании сложной радиоэлектронной аппаратуры. Были очень старые нормы, 60-х годов, заказчик(военные) не захотели их больше видеть, типа у вас и компьютеры и техбаза другая. Вот и попал в эту кашу. А там и разработка аппаратуры разных типов, разработка ПО опять же разного направления от микропрограммного до алгоритмов боевой работы, изготовление, включая железяки, и аппаратуру, испытания, приемка заказчиком, транспортировка до об'ектов, монтаж, настройка, ввод в эксплуатацию, обслуживание, ремонты, вывод из эксплуатации, утилизация. В общем все этапы жизненного цикла изделия, включая работу с документацией.
Согласись, что работа по формализации норм во внедрении 1с просто несопоставима. Просто этим никто толком не занимается.

(0) А разве РП за что то отвечает ?  Главное шум создать ..:)

+(71) это просто современный тренд... проектный офис , РП  и т.д. Стильно , модно ,молодежно-инстраграммно..

(70)    Интересно ... какого уровня нормы трудоемкости  детализации изделия ? Уровня монтажа платы  где используется 30- 50 старых микросхем 155- ЛА3(ЛА5)  или   уже блока  где эти платы используются ?

Нормы рождаются просто. Есть несколько способов. Самый просто экспертный: эксперты говорят, я эту мелодию угадаю с... Если нет примера для экспертной оценкииногда делают так: можно разбить задачу на операции. Ззасекается время исполнения. Далее вводят эту норму на какое-то время. По истечении времени, норму корректируют.
Конечно там учитывается сложность, специфика, квалификация.

(70) сначала разработка, потом выпуск КД, затем технологическая подготовка производства, затем изготовление составных частей(может быть закупка), потом только монтаж. Включая микропроцессорную технику.

+(75) разработка ПЛИС в том числе. Мне внутрь особо лезть не было нужды. Это была ответственность разработчика. Моя задача была обобщить результаты, классифицировать и автоматизировать расчёт стоимости изделий.

Добавлю. Не подумайте, что вопрос нормирования решён. Я по многим предприятиям бегал, практически везде пустота.

А эти нормы включают время на изучение некой технологии?

Суть в том что тут время в часах обычно а в этом вашем "ПЛИС" время в чем измерятся? В днях? В неделях? В месяцах?

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

(78) С какой стати заказчик должен платить за обучение сотрудников исполнителя? Особенно если ему называют стоимость 1 часа работы СПЕЦИАЛИСТА?

(79) С той стати что специалист знает платформу а не конкретное решение-конфигурацию используемую заказчиком.

(78) там были коэфф, которые начинали работать, если разрабатывалось ноу-хау , в случае с разработчиками ПО, учитывалась только квалификация, типа сертификатов. Если разработчики применяли или пытались применить новую технологию, а сами в ней ни бум-бум, то могли себе помочь только разделом 'сложность'. Даже если потом применение этой технологии сокращало трудозатраты. Но заказчику это не нужно было знать. В качестве подобной технологии могли быть системы коллективной разработки.

(80)+ А еще бывают разные приколы когда пишется нечто внешнее относительно 1С.

Вот пример Хелп! выгрузка файла POST запросом и тут можно и пару дней провозиться ибо ну не принимает внешний сервис данные от 1С и хоть тресни, пока не разберешься почему не принимает болт.

(80) Тогда что он тут делает, если не знает конфигурацию? Ну и конфигурация под "некую технологию" не подходит.

(82) А вот для этого и пишут ТЗ. Если все сделано по ТЗ и не работает - заказчик все равно оплачивает работу, и потом платит еще за переделку, чтобы работало. Или перенастраивает свои ИС чтобы сделанное в соответствии с ТЗ работало.

Кстати. Когда оценивают трудоёмкость, не обращают внимание на затраты на стоимость инструментария, каким будет произведена работа. Особенно в части разработки наукоемких изделий. Я им туда навтыкал коэфф учитывающих применение стоимостей лицензий САПР, серверных решений, ЧПУ и многая чего. Особенно, обновлений этих лицензий.  О временем заказчик согласился.

+(83) обычно надо делать доп к ТЗ.

(83) "Некая технология" подходит под что угодно в т.ч. под конфигурацию.
Или у вас тоже работают некие "суперисполнители" которые все-все конфигурации наизусть знают?

Дайте спецу по ERP2 банальную Розница2 Аптека и что он там наваяет?
Пока не разберется в предметке и особенностях учета и ценообразования вместо каждого часа будет *X, где X зависит от способностей исполнителя к обучению.

(86) *ERP или KA2

(86) Тут все просто: не надо лезть туда, где у вас нет компетенций. Сначала заимейте спеца по Розница2 Аптека, а потом уже предлагайте свои услуги. А то наваяете там велосипедов...

(88) А проблема что нету под рукой обычно со всеми компетенциями, приходится решать задачи теми исполнителями что есть.
И да тратить время в т.ч. на обучение исполнителя за счет заказчика или за счет работодателя.

(0)Все просто. Это франч и тут ты будешь всегда в убытке, если работать честно. РП всегда будет немного занижать время на задачу, чтоб проще было ее продать. Если ты профи, то ты сможешь просчитать заранее сколько затратица времени и оспорить, иначе будешь учиться себе в убыток. Так собственно все начинают. Затраты 5ч и 45ч сильно разнятся. Если вы уверены в своей правоте то я бы потребовал чтоб вам доказал РП что задача делается за 5ч. Правда если он действительно сделает за 5ч или близко к этому то вам долго придется молчать в тряпку :) Опять же надо не забывать что оценка часов идет как часы профессионального программиста, а не часы исполнителя. Бывают поблажки и например оценили задачу в 8ч, но знают что клиент может заплатить больше и вы не очень сильный прог, то вам ее могут дать на 12ч. В итоге вам надо вырасти в прога который умеет оценивать работу и отстаивать свою правоту, а потом вырасти в того с кого не будут спрашивать сроки и время затраты заранее, а будут просто платить и радоваться что вы у них есть.

(89)+ или за счет исполнителя

Согласно (90) если заказчик или работодатель хотят сэкономить.
Интересно как это согласуется с ТК, когда за те же деньги по сути заставляют перерабатывать?

+(90)Обучение всегда за ваш счет. Единственное, если РП не козел, то он будет вам давать задачи по вашему уровню или по одной тематике, чтоб вы учились на этих же задачах, тогда затраты на обучение можно будет снизить, но все равно это будет ваш убыток. *Проф час - это грубо говоря сколько времени потратится при повторном решении вами этой же задачи, учитывая что первый раз вы решили ее как надо и нужными средствами. (понятно что по факту есть моменты, которые нельзя было предугадать и их нужно брать как затраты времени и в первый раз)

(91)А не перерабатывать вы будете только работая на себя.

(93) Как раз, работая на себя, берешь и все риски. Оценил в 5часов, а потратил 45? Только твои проблемы.

(94) +1

Опередил, только хотел написать что "на себя" это как раз сплошная переработка

(94)Поэтому сразу ты не можешь работать на себя. Сначала надо стать профессионалом своего дела. Погрешности в оценке компенсируются, тем что не будет РП, которому надо платить ЗП и ряда другого персонала.

(89) Это ведь ваша проблема - так что и тратьте свои деньги. Когда вы идете к заказчику - он исходит из того, что вы разбираетесь в теме. Ну или честно скажите: мы в этой теме ни бум-бум, будем на вас учиться, поэтому +500% к цене будет.

(97) При текущей ситуации на рынке ИТ это скорее проблема заказчика.

(98) Необразованных как раз полно. Не хватает именно профессионалов. И тут, внезапно, более-менее крупному заказчику становится выгоднее иметь свой штат, чем платить за отчет средней сложности, который 1 собственный специалист сделает за неделю его месячную зарплату, да еще и грузиться согласованием ТЗ, чтобы на еще 2 месячных зарплаты не попасть.

(99) Про это и написал, что в итоге все сваливается на заказчика, все затраты.
Если он хочет качественно и в срок то это получается дорого.

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

(100) Свой спец в 3-4 раза дешевле по затратам, чем платить франчу за нубов, обучаться он может в свободное время между задачами (за 1-2 месяца он уже вникнет в тему, и затраты на обучение обнулятся), кроме того, он снижает затраты времени руководителей за счет отсутствия ненужных совещаний на тему как заставить франча делать что нам надо не платя по 5 раз, а это нехилая такая экономия как за времени руководителей, так и на расходаах на сторонних подрядчиков. А во франче обучать надо будет каждый раз, да и не понимает там программист что он пишет обычно.

(101) Согласен но свой спец он всего один и знает нечто хорошо обычно в неких достаточно узких рамках.
В случае же найма франча можно найти того у которого дофига разных спецов, которые покрывают практически все что угодно.

Т.е. конкретная "выгода" или "затраты" сильно зависят в итоге от задач.

(57) повторю

если реально отчёт сделать за 8 часов, а он сделал за 58, то конечно 58 не оплачивают

(68) и на кой хрен мне исполнитель, если я вот это всё распишу уже до таких молекул? Быстрее уже самому и сделать. Я, кстати, об этом и говорю - чтобы оценка сошлась с фактом, надо на 80% все решить.

(70) материальное производство с программированием некорректно сравнивать. В программировании ни законов, ни науки никакой. На текущем уровне развития - это ремесло.

(104) >На текущем уровне развития - это ремесло.

Скорее нечто среднее между ремеслом и искусством, приправленное техникой.

(105) именно

сколько надо времени, чтобы мону лизу написать? Да Винчи 4 года писал - это норматив? Да хрен там, это просто 4 года. Нет никакого норматива.
Несмотря на то, что картинопись для Да Винчи была профессией, хрена лысого у него были какие-либо нормативы. Забор побелить - вот тут есть нормативы, только кому они в хрен нужны.

(107) Мона Лиза в данном случае, скорей всего, перебор.

Но со смыслом твоих аргументов, наверное, все согласны.

(104) Так если исполнитель не общается с заказчиком, и вообще не в теме - по-другому он просто не сможет нормально выполнить задание. У него в процессе выполнения появится столько вопросов, что замучаешься отвечать.

(107) Проблема в том, что до Моны Лизы франчам как до Китая раком...

(103) это был пример.

на деле задача другая, совсем другая.

Если один раз проимелся - не ошибается только тот, кто не работает. Если это систематическая проблема - делаем выводы о некомпетентности РП со всеми вытекающими.

Оценили задачу в 8 с согласованием сделали за 45-ок,рп в курсе
Дальше его проблемы - согласовать часы с заказчиком или оплатить их в счёт маржи или резерва, или в следующем спринте их снять.
Про походы к директору - спасибо, поржал, для директора это самый важный вопрос=)

Тема не о чем. Эти дела кодера вообще не касаются. Это тема для РП и руководства фирмы. В конце концов сумма 50-60 тыс., если проект стоит несколько лимонов- копейки

(0) Не совсем понятно к кому обращен вопрос "что с этой проблемой делать?" - к исполнителю, руководителю проекта или заказчику.

Если речь про исполнителя, то его дело маленькое - заявить РП о просчете ДО того, как приступить к исполнению или как можно раньше, если работы уже начаты. Если РП принимает решение о том, что делать всё равно нужно, то он тем самым обязуется оплатить работу исполнителю (ну или они как-то обговаривают этот момент). Если нет - тут уже вопрос решается индивидуально в зависимости от того, сколько уже фактически потрачено на работу, которая сдана заказчику не будет (поэтому важно известить РП о косяке как можно раньше).

Если речь про РП - его задача включить талант продавца и бежать к заказчику с тем, чтобы пересогласовать заново стоимость проекта и новые сроки, графики и планы. Тут возможны несколько вариантов. Заказчик может отказаться от требуемого функционала вообще, если он не критичен или его можно как-то иначе реализовать. Заказчик может согласовать какой-то иной менее трудоёмкий способ решения, который уложится в оговоренное ранее время. Заказчик может встать в позу и отказать что-либо оплачивать сверх того, что прописано в договоре. В последнем случае, если никак не удаётся убедить заказчика, РП придётся принимать сложное решение - как не обидеть исполнителя и чтобы заказчик был доволен. Если проект состоит из множества этапов, то просчет "в минус" на одном из этапов можно нивелировать за счет просчетов "в плюс" на другом. Для этого трудозатраты рассчитывают всегда с хоть каким-нибудь запасом.

Если речь про заказчика, тут относительно просто. Заказчик либо может пойти навстречу РП и войти в положение, либо встать в позу и требовать строгого соблюдения бюджета и сроков. В последнем случае он будет в своём праве и с формальной точки зрения продавить его довольно сложно. В особенности если предпроектное исследование и планирование было оплачено отдельно и заранее.

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

(113) // Про походы к директору - спасибо, поржал, для директора это самый важный вопрос=)

Ну если из-за такого прое@а от РП регулярно разбегаются все Разрабы, то как-то и директору придется подписывать заявления или на перевод или на увольнение.

(109) > если исполнитель не общается с заказчиком,... он просто не сможет нормально выполнить задание.

Чушь. Исполнитель не должен вообще общаться с заказчиком. Для этого есть РП.
Максимум на этапе сдачи-приемки, где требуется какое-то обучение пользователей или сложная демонстрация результатов.

> в процессе выполнения появится столько вопросов, что замучаешься отвечать.

Вот пусть РП на них и отвечает. Он должен быть в теме. Только у него есть понимание - что и для чего нужно в проекте.

Как только Заказчик начинает напрямую общаться с Исполнителем проект превращается в полное *авно, где заказчик выворачивает идею проекта с ног на голову, начинает выдумывать какие-то свои требования. Не говоря уже о случаях, когда внедрение проекта связано с перестроением бизнес-процессов, а заказчик продолжает по инерции требовать реализовать старый бизнес-процесс потому что "мы так всегда делали" и "нам так надо!".
Потом после такого "общения" исполнителя с заказчиком приходит РП и понимает, что вся модель проекта начинает накрываться женским половым органом потому что заказчик с программистом занимаются расстановкой кнопочек на форме "как было раньше" и рисованием отчетов, которые делали последние 10 лет, не зная, что отдел-получатель этих отчетов складывает их в мусорное ведро.

(52) У меня вся схема расписана вроде на достаточном для однозначного понимания уровне. Какие могут быть еще вопросы?

(116) хрень какая то.
Если это вопрос компетенции разраба то по решению рп просто выплачивается 8 часов и все, если это проблема в коммуникации между рп и разработчиком, то здесь можно и позвать кого то разрулить вне конфликта

Незаменимых нет,)

(116) > если из-за такого прое@а от РП регулярно разбегаются все Разрабы.

Это уже отдельный вопрос, который директор и будет рассматривать, когда и "если" он реально возникнет. Вообще вопрос с разбегающимися разработчиками к теме ветки не относится. От одного случая просчета РП программисты не сбегают.

А вникать каждый раз в какой-то там отчет какого-то там заказчика директор точно не должен. В каком-то сложном  случае, если РП не может договориться с программистом о переработке, или у него недостаточно полномочий для принятия решения, директор может выступить арбитром.

(119) Такая же эскалация, как и при конфликте РП заказчика и рп исполнителя

Рекомендую книгу дедлайн, там описаны почти все самые распространенные психотипы рп

с их косяками и фишками

(119) (120) да просто такая хрень регулярно происходила в .... не буду говорить каких франчах. И я лично в это вляпывался и мои друзья об этом же говорили. Разработчики регулярно конфликтуют с РП в большей или меньшей степени.

Это обычная даже практика, когда РП режет часы своему Разрабу до тех пор, пока не создастся конфликт. А затем все вынуждены в этом конфликте принимать решения и в условиях, когда Разраб изолирован от Заказчика - а это бывает и полезно, и вредно для работы с Заказчиком. Чаще бывает вредно. Т.к. при наличии параллельного контакта Разраба с Заказчиком процесс уходит в негатив очень быстро.

Но смысл моих рассуждений в том, что Разраб один черт получает не столько, на сколько разводит Закачика РП, а ровно столько, сколько ему согласен "закрыть" в часах РП. И отсюда очень простой вывод, что оплата не на окладе, а на почасовке == зло для разработчика.

(0) "что с этой проблемой делать?"
Ну как обычно пишут всякие эйчары, писатели тернингов и прочие ничего не понимающие в том что говорят: развивать скилы коммуникаций, выходить на новый уровень, бла-бла-бла.
В итоге ты хоть так хоть эдак без бабла.
А можно свалить из этого цирка (франча) на фикси и греться на солнышке.

(0) Если руководитель ошибся с оценкой трудозатрат, то пусть сам и делает за 8 часов

(124) жизнь несправедлива, что поделать:)
(123) такие книжки надо в 20 читать, я читал в 30 и все свои косяки там нашел=)

(127) А я и читал ее в 24

вру в 22

а что разработчику не озвучивалась оценка?
почему разраб не оповестил что будет превышение заранее.
те решение должно было быть принято до того как задача сделана на 45 часов

(124) от франча зависит. у нас, например, незакрытые часы аналитику или программисту - это нонсенс.

(126) какая агрессивная политика

(132) За свои ошибки надо нести ответственность

(133) Иногда можно как говорится "сделать скидку", т.е. снизить требовательность / строгость / критику :)

(122) том де марко? читал

(134) Так уж  быть прощу начальнику, но чтобы это было в последний раз))

(136) На самом деле ничего смешного тут нет - подчиненный именно прощает начальнику его (начальника) косяки

(0) У нормального РП всегда есть резерв. Я процентов 15 закладываю на непредвиденные "расходы". Но тратить его бездумно нельзя. Для начала попробовать договориться с заказчиком на допоплату с обоснованием возросшего объема, который нельзя было оценить заранее. Если не согласится - попробовать другие задачи "проинтвентаризировать" - возможно можно сманеврировать. Если не удается - использовать резерв. Если и резерв прожрали - готовить банку вазелина.

(138) РП не может ничего "закладывать" (резервировать), т.к. у него нет компетенций какую-либо оценку в принципе давать

+(139) Т.е. он может лишь накинуть сверху ("заложить") от оценки, полученной от компетентного человека

(139) Поэтому у РП и должны быть эти компетенции.

(141) Про "должны" это конечно же не так, т.к. почти всегда это не так

(142) Значит, хреновый это РП.

(143) Не спорю. Но функции барьера, актирования, дипломата выполняет и уже хорошо )

+(144) Отсутствие компетенций по теме проекта можно и простить, если есть другие компетентные люди

(124) > оплата не на окладе, а на почасовке == зло для разработчика.

Есть два принципиально разных вида деятельности и вида разработки. Рассчитываются и оплачиваются они совершенно  по разному.
Первая - проектная. Система оплаты окладная + премия за закрытые проекты (этапы проектов).
Вторая - поддержка и сопровождение. Система оплаты почасовая.

Там, где пытаются подменять одно другим или как-либо смешивать, происходит бардак.

(139) >> РП не может ничего "закладывать" (резервировать), т.к. у него нет компетенций

В обсуждаемом в этой ветке примере РП и архитектор - это одно и то же лицо. А архитектор как раз и обладает компетенциями по оценке трудозатрат. Он то четко должен отличать отчет, который просто отчёт, от отчёта, который потребует создания или изменения регистров, документов (регистраторов) или любой другой значительной доработки конфигурации с соответствующими трудозатратами.

(139) Речь идет о резерве трудозатрат по проекту в целом, и не об оценке трудоемкости задач. Архитектор дает мне 100 часов. Я закладываю в проект 100 часов + 15 часов резерва. Заказчикам, ессно рисуется 115, т.к. они очень нервно реагируют на слово "резерв". Но если заказчик вменяемый, то оставляю резерв отдельной строкой. С отдельными отчетами об использовании этого резерва. Практика показывает, что первоначальные оценки всегда заниженными бывают. Если в целом  по проекту считать.

(148) Ясно, ситуация из (140). Я неправильно значит понял твое "Я ... закладываю" - подумал, что ты это делаешь когда и оценку самолично придумываешь )

(139) Лол

(147) Ничего архитектор не может оценивать, ибо не погружается в каждую лужу глубоко

(148) Тут еще нюанс что каждый спец всегда оценивает по своему, кто-то оценку занижает, кто-то завышает, кто-то попадает в срок

(151) Не придумывай

(152) Чаще всего заниженная. Одноэсники неисправимые оптимисты. Даже если предварительную оценку умножают на число пи. Они почему-то наивно полагают, что правильно поняли что хочет заказчик :)

(154) по моему опыту, оценка будет зависеть от квалификации + психотипа

(155) Ну если последнее предполагает, что число пи несколько заниженное, то да :)

(117) А что если почитать несколько предшествующих сообщений, где речь шла о том, что РП должен составить подробное ТЗ, иначе вопросы программиста сорвут все сроки?

P.S. Когда Исполнитель не общается с заказчиком - получается то же самое г, только в профиль, если не составить подробнейшее ТЗ, чтобы его нельзя было сделать неправильно. Потому что чтобы задать правильный вопрос - надо наполовину знать ответ, а без общения с заказчиком он ничего не знает. Ну или РП просто зашьется и не будет успевать отвечать и консультировать всех прогов.

(157) Самое плохое это когда РП сам не знает для чего надо то, что он отдает в работу исполнителю

(154) На 7 же надо умножать: семь раз отмерь...

(158) Вот для этого и нужна связь обоих с заказчиком: РП как модератора хотелок и исполнителя, который будет реализовывать хотелки в контексте того, что предполагается решить. Тогда он сможет задать правильный вопрос. И если РП не знает - так хоть исполнитель может поймет :) Плюс исполнитель может предложить такой вариант, который будет проще реализовать (РП ведь может и не был программистом, и не знает, какие возможности есть "из коробки", а какие повлекут очередной велосипед).

Всё не читал, но вина исполнителя.
Всем известно, что рыба с головы гниет, но чистят с хвоста - всё остальное лирика.

(161) Только на вакансию руководителя приходится 20 претендентов, а на вакансию разработчика 2

(7) Сегодня сказал делать отчет на 45 часов себе в убыток, а потом заключил с ними контракт на 45 млн.

(160) Собственно, все это не нужно, если РП правильный, а именно знает ответы на 4 вопроса: кто, что, когда и зачем.

+(164) Связь исполнителя с заказчиком нужна только тогда, когда РП с хлебушком. В иных случаях двойной контроль-переваривание хотелок заказчика (и РП, и исполнителем) кажется избыточным.

2(162) РП продажник хочет продать за 8, а назвался грибом - исполнитель взял работу - делай.
Сейчас практика пошла - разработчик - это тот, кто не хочет на себя ответственность брать, и попробуй докажи, что огород который он нагородил - это необходимо.

(166) Вообще-то сначала поступает заказ, а потом его исполняют. Вариант когда сначала делают конфигурацию, а потом ее продают, разработчик выступает собственником и несет всю ответственность, и сам продает свою конфигурацию

(139) это вы не рп описали, а "эффективного менеджера" - сову с пикабу

(167) Поток сознания какой-то. В бред переходящий

(168) Я оперирую ролями, а не носителями оных (человеками). То что ты там что-то совмещаешь или видел таких кто совмещает несколько ролей суть самой роли не меняет.

(170) крупные проекты?

(169) Разжую. Этот перец мне заявил, разработчик наваяет, что ему только в голову придет, а руководителю проекту потом это приходится продавать заказчикам. Я же говорю что происходит наоборот, сначала заказчик говорит что ему хочется, а потом разработчик реализует его хотелки.

(172) Причем тут тп и проект?

(170) В жизни нет ролей, в жизни есть конкретный рп с конкретной командой, которую он строит под себя, в рамках мотивации компании

(151) > Ничего архитектор не может...

Ну конечно. В твоём мире программист - это альфа и омега, человек на котором свет клином сошелся и только он один способен понять что конкретно нужно заказчику, как именно это должно быть реализовано и сколько времени это займёт. А РП, архитекторы, методисты, консультанты, технические писатели, тестировщики - это всё люди - так себе - мимо проходили, пописать зашли.

(165) Здесь вопрос в качестве реализации и удовлетворенности клиента (что в будущем дает дополнительные продажи, т.к. наевшись обычных франчей, которые делают сферических коней в вакууме, и найдя такого, который понимает - клиент будет за него держаться). Когда и РП, и исполнитель знают, что делают - существенно снижается риск испорченного телефона, который зачастую приводит либо к убыткам, либо к неоплаченным работам, а также сорванным срокам, ну и клиент недоволен, само-собой.

(175) Что-то ты тупишь: сказано какую функцию он не выполняет. Это не означает, что он не выполняет никаких других функций.

(174) Все так. Главное противоположных психотипов наедине не оставлять)

(157) ТЗ должно быть составлено таким образом, чтобы исключить необходимость общения исполнителя с заказчиком и делать достаточным для решения любого возникающего вопроса общение  программиста с РП (автором ТЗ).

Насколько ТЗ будет детально прописано может зависеть от конкретного исполнителя. Для тупого кодера надо всё по полочкам расставить, разжевать и в рот положить. Для более опытного специалиста достаточно будет общего описания с подробными акцентами только в нужных местах.

Любое общение программиста с заказчиком только вредит проекту. Если есть ТЗ, то необходимости в таком общении просто быть не должно. Это нонсенс. Иначе зачем вообще ТЗ нужно? Посадите программиста за стол с заказчиком и пусть он кодит под диктовку заказчика.  Только потом не удивляйтесь, что на выходе получается какой-то в хлам переписанный монстр, не способный работать без костылей и прямого пользовательского вмешательства в записи регистров, а отчеты получаются только через ручную допобработку выгрузок в excel.

В исключительных случаях программист может привлекаться в качестве технического консультанта на этапе составления ТЗ. Когда автору ТЗ (РП, архитектору, методисту) не хватает знания и опыта - как именно лучше реализовать ту или иную задачу.

(176) Ну тогда уже получается, что один делает часть работы другого. В общем случае это неправильно, в частном отсюда конечно же не видно.

(177) >> сказано какую функцию он не выполняет.

Только не надо эту функцию (оценку трудозатрат) передавать программисту.
Повторюсь: в нашем примере РП совмещает обязанности архитектора. Он оценивает трудозатраты и обладает для этого всеми компетенциями. Программиста он конечно тоже может к этому привлечь, но в каких-то исключительных или сильно сложных случаях.

(179) про ТЗ все понятно, а как методист может написать ТЗ, мне вообще кажется кроме программиста ТЗ написато никто не может, методолог тоже человек и то что, очевидно ему не очевидно программисту.

(182) У тебя какое-то извращенное понятие о программисте.
Программист вообще не должен писать ТЗ. У него несколько другие задачи.
Авторами ТЗ как раз и являются архитекторы и методологи. Люди работающие на стыке прикладной части, конкретной конфигурации и конкретной платформы.
Программистов могут привлекать (и регулярно это делают) в качестве технических экспертов для оценки и выбора конкретного решения в каких-то особенных случаях.

(183) ты давно вакансии на HH смотрел? в обязанности программиста входят знание БУ и УУ ) соглашусь во франчах квалификации программистов ниже там не требуют.

(183) Техническое задание и проектная документация наверно разные вещи, думаю ТЗ написать может любой, так же как и заказчик обрисовать что конкретно ему нужно, а вот проектную документацию методолог написать не сможет, там пообъектно что куда и откуда

(181) "в нашем примере РП совмещает обязанности архитектора" // Хз что за наш случай, не слежу за веткой.
В любом случае если архитектор поголовно каждую задачу оценивает, то это точно не архитектор.
Архитектора основная функция - гнать стадо кодеров и тимлидов в нужном направлении, а если впереди обрыв или дождик пошел то увести оттуда и зонтик раскрыть, опционально - солнышком приправить.

(185) Он как и большинство просто путает ТЗ и ТП (тех. проект). Вот ты не путаешь, но это 1 из 10 наверное только.

(179) У франчей нежизнеспособный монстр на костылях обычно получается и без общения исполнителя с заказчиком. Это типичный результат работы франча. Потому что идеальное ТЗ - это из страны, где единороги кушают радугу.

А насчет "Насколько ТЗ будет детально прописано может зависеть от конкретного исполнителя" - это беспечность. ТЗ должно быть достаточно для самого тупого человека, потому что в суде любая недосказанность в ТЗ, подписанном сторонами, будет оспариваться. Поэтому если делать ТЗ рамочным - надо сводить к минимуму риск непонимания. И РП, который интерпретирует задачу для исполнителя, в данном случае слабое звено. Если он понял неправильно задачу - все, тушите свет.

Кроме того, опытный исполнитель вне контекста просто не сможет работать, т.к. у него, в отличие от тупого кодера, возникнет множество вопросов. На часть из них даже РП не сможет ответить, т.к. он до такого уровня просто не детализирует в разговорах с заказчиком.

(183) например? вот нужно своять печатную форму к отчету, как будет выглядеть ТЗ от методолога? макет печатной формы? и короткая инфо? или он будет привлекать программиста, я вот думаю методолог это своеобразный эникейщик, который права пользователям раздает общается с клиентом, он же продажник иногда бывает..

(184) требования знания БУ и НУ - копипаста, почему то очень модная.
Если программисты принимают решения по методологии, а не специалисты отделов - это не программисты.

(190) по факту я до сих пор не знаю БУ и НУ - для этого в штате есть спецы по этому, я перекладываю это в код, не более

(180) Это не совсем правильно идеологически, но зато позволяет при правильной организации повысить качество продукта и уменьшить сроки. Это как с нормализацией данных.

(190) а кто круче программист или методолог? кому зарплату больше платят? программист работает с данными, он знает пообъектно все регистры, знает что куда откуда и почему, работает с данными способен проанализировать любую ошибку в системе, способен изобразить ТЗ и ПД, методолог думаю без знаний программиста тоже самое изобразить не сможет..

(191) т.е. работая программистом ты не постиг БУ и УУ, либо мало работаешь или профессия не та выбрана т.е. тебе тупо не интересно? работа ради работы? потому что платют много?

(192) Если принять как факт утверждение "в общем случае РП в роли одного физического человека никогда не может собрать информацию от заказчика с достаточной полнотой" (хотя критерий достаточности в (164) отлично работает), то отсюда вытекает, что роль РП должна быть размазана как минимум между двумя человеками. Тогда уже исполнение функций ими обоими уже не кажется неправильным. Но почему-то в такой постановке функция РП "собирать данные от бизнеса" никогда не видел чтоб преподносилась / не распределялась официально.

(193) Каждый хорош на своем месте.
ЗП сопоставимые.
При составлении ТЗ идёт парная работа.
Консультант говорит что и как должно быть с точки зрения учёта, а ппограммист( на самом деле ведущий и выше) говорит как это будет сделано на уровне кода, или что надо изменить в модели, что бы это было возможно реализовать.
Времена самоучек - спецов по всем вопросам прошли.

(196) Уровень ларьков я не рассматриаю

(196) если по ЗП одинаково то я лучше методологом чем программистов ковырять этот говно код.

(196) мне сложно судить, а роль РП какая? если есть методолог который задачу программисту ставит?

(196) лично я считаю что по иерархии методолог должен быть выше программиста, человек который не только может сам написать код но еще и понимает методологию программы., а то что вы называете методологами самые что не на есть обычные консультанты или линия тех.поддержки., имхо.

(195) Руководитель должен быть один, иначе не взлетит. А вот входные данные собирать можно с разных точек, чтобы в итоге как можно полнее понимать, что делается, зачем и чем это полезно заказчику.

Программист, например, может предложить альтернативное (более простое или с использованием типовых механизмов) решение, зачастую при этом даже более юзабельное и понятное, потому что он знает КАК он это будет делать, и сколько велосипедов надо будет изобрести для реализации "как сказал заказчик". Т.е., фактически он выступает в роли технического эксперта, но совмещение этой роли с ролью программиста дает синергетический эффект, поэтому лучше когда это один человек.

(201) "Руководитель должен быть один, иначе не взлетит" // Я поэтому и написал только про одну "функция РП ... распределялась" :) Ну вот не видел почему-то чтоб вверялось такое исполнителю официально. Неформально исполнитель конечно (каждый в меру своего психотипа и чувства прекрасного) скорее всего будет эту функцию нести.

(200) Методолог все-таки ближе к бизнес-аналитику. На прикладную функциональность конкретного ПО ему должно быть пох. Это уже консультант по ПО перекладывает методологию на это ПО.

+(203) И поэтому да - исполнитель (разраб) в паре с консом обычно работает. С методологом ему общаться не приходится.

(0) Если всё как ты говоришь, то РП должен иметь яйца и вывернуть карман.

(1) Если прогер опытный и видит что не так оценили, шлет всех сразу далеко, пока ему не дадут ответ кто будет платить. Обычно за это ему ничего не бывает. А если бывает, то у этой фирмы опытные программисты быстро исчезают.
Ну а если не опытный, то скажут что ты еще просто ничего не умеешь и расскажут сказку о том как у него все будет хорошо. Правда не опытный на 45 часовой задаче, на месяц застрянет.
Как вариант, завышают затраты на всех заказах, что бы было откуда компенсировать промахи.

(35) как минимизировать

Дробите работы на этапы так, как удобно вам и как согласится заказчик. Хоть по 40 часов ))

И выделяйте отдельно разработку ТЗ по этапу.

То есть, даете оценку на ТЗ, согласуете. Оценку на остальное в рамках этапа - даете предварительную.
Сделали ТЗ, его согласовали. Дальше, переоценили остальную часть. Пошли согласовывать оценку у заказчика.
Согласовали - пошли кодить.

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

И т.д. )

(0)вариантов куча: 1. расстрелять 2. уволить 3. лишиь премии 4. поругать перед подчиненными
все бываает, а можно простить и понать

(208) За п.4. нужно увольнять за профнепригодность того, кто такое предлагает.

(209) плюсану

(0) Кто угодно может ошибиться с оценкой трудозатрат.
Что делать зависит от того, что хочется получить.
Для более точной оценки задач
- можно делать оценку группой людей голосованием (Как правило руководитель и исполнители). В скраме это называется "poker planning".
- задачи нужно разбивать на подзадачи что бы 1 задача не занимала больше 2-4 дней (зависит от типа задача).
- выставлять эстимейты после начала выполнения, когда ясен фронт работ.
Для минимизации рисков
- как можно раньше сообщить о неверных плановых сроках. Заказчику подробно рассказать как рассуждал и ошибся и обосновать новые сроки.

(208) Выставлять ошибку на общественное порицание - последнее дело.
Накосячил - ну ладно выеби, но за закрытыми дверьми. Это дело 2х - подчинённого и руководителя, но никак не всей толпы.

(196) Вот полностью согласен.
И на практике такая связка дает результат. Бизнес аналитик или методолог, называйте как угодно, собирает инфу, консультируется с ведущими программист или группой, или отделом ИТ аудита, и в итоге рождается ТЗ. ТЗ в зависимости от сложности попадает или ведущим или просто кодерам.