Валентин

Устранение баг в сданном продукте относится к этапу гарантии. Стоимость такого этапа оценивается в диапазоне от 5-20% в год от стоимости создания (лицензии?). Процент в указанном диапазоне максимален для заказной разработки и уменьшается в зависимости от количества повторяющихся инсталляций вашего программного продукта.

Значит делать в рамках одного договора, а промежуточную оплату проводить как аванс. Но такое возможно только при единовременном авансировании. Если все же нужна этажность, от отдельных заказов не уйти, иначе как будете спорить на счёт исполнения обязательств в полном объеме за определенный этап?
Ну или разбейте на фиктивные этапы, без выполнения которых задачу не решишь: разворачивание опытного участка, ввод в промышленную эксплуатацию, сдача документации.

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

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

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

Ни разу не сталкивался с ТЗ по 19 (ЕСПД), но постоянно работаю с ТЗ по 34 (АС). Тем, кто говорит, что ГОСТ это про бюрократию, рекомендую в ограниченные сроки создать автоматизированную систему с нуля хотя бы масштаба одного города, в которой будут работать хотя бы человек 20, поработать с инфобезом по ней. Сразу станет понятно, для чего ГОСТ 34 нужен, и ПМИ для чего, и проект на систему.

Как-как, вот тебе план - сделать за неделю, не сделал -премия, сделал за три дня +премия.
Вот обычно критикуют наличие нормальных должностей вида инженер/старший инженер/ведущий инженер/эксперт и т.д. а зря. Если прозрачна штатная структура и система назначения, то все отлично. Мы малоактивным инженерам этим примеры роста показывали.

Рисование для дилетантов. Профессионалы используют PlantUML

системный администратор

Классификатор аварий по ущербу и плановых работ, количество аварий за отчетный период, количество проведённых плановых работ, количество изменений на оборудовании

сервисный инженер

Количество выездов

системного техника (aka эникейщик)

Количество отработанных заявок.

Принцип таков - вся рутина классифицируется по показателям, считается вклад задач в достижение целей компании, выводится KPI (норма) на сотрудника в соответствии со средними значениями за предыдущий период.

Я делаю так: представляю шкалу процентов и времени. Т.е. с вероятностью 80% я сделаю это за неделю. Торопят быстрее? За три дня я сделаю это с вероятностью 20%. Откуда такие цифры? Из опыта, подтверждённого задачами из системы постановки задач.

В п3 у вас описание бизнес-логики вашей организации. Это допиливание софта под ваше ТЗ. Естественно, это не бесплатный процесс с несколькими циклами доработок.

Цель ТЗ - формализация задания в понятный вид исполнителю. Посему надо:

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

У таких людей уже не почасовой KPI, а попроектный (решено столько-то проектов в квартал/год). А там свои м5тоды оценки.

Excel наше все. Цветами активнее играйтесь и условным форматированием.

Открываете хедхантер и смотрите вакансии в разделе информационные технологии/телеком в каком-нибудь крупном городе.

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

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

Пишите в личку на хабре авторам статей, которые вам понравились. Только учтите, что ценник будет не 80-100 р за 1k символов.