Комментарии 20
Зуб даю, что после всей формализации у вас оценка на единицу функциональности выросла в два и более раза. Так как задачи чаще всего не делаются сильно раньше срока и сильно дешевле бюджета, то вы даже не можете оценить точность попадания, ибо любое превышение оценки над реальной потребностью незаметно съедается.
Оценка стала реальней. Основная суть в том, на мой взгляд, что чтобы дать оценку более менее верно нужно раздробить задачу на массу взаимосвязанных подзадач. Как правило это позволяет не пропустить чего-то важного. При этом оценка точно получается точнее когда разделяешь все на мелкие части. Но да — это трудозатратно.
Там еще дополнительный вопрос. Делить все на элементы или на архитектурные части. Скажем часть разработчиков пытается делить всю работу на работы по БД, сервисы, клиентская часть. Другой подход делить все на элементы. Например, для интернет магазина это будут Home, каталог товаров, контакты и вплоть до мелких элементов таких как отдельные кнопки, контролы и т.п.
Там еще дополнительный вопрос. Делить все на элементы или на архитектурные части. Скажем часть разработчиков пытается делить всю работу на работы по БД, сервисы, клиентская часть. Другой подход делить все на элементы. Например, для интернет магазина это будут Home, каталог товаров, контакты и вплоть до мелких элементов таких как отдельные кнопки, контролы и т.п.
Если пытаться декомпозировать задачу сверх вашего понимания её решения, то вы неизбежно чтонить упустите. Например вы всегда занимались СЭД, которые работали на 100 пользователей, а внезапно вам надо сделать чтобы работало на 100000. Вы уверены, что при оценке такой задачи вы ничего не упустите? Я уверен в обратном.
Чтобы реально ничего не упустить нужно собственно выполнить проектирование, и, скорее всего, сделать прототип. Но если заказчик эти работы не оплачивает, то это крайне большой риск. Увы. Я предпочитают продавить проекты с поэтапной оплатой, чтобы сделать прототип за счет заказчика. Тем более что прототип заказчику нужен также, как и мне, так что это win-win.
Если же вы знаете как реализовать проект, то детальная декомпозиция вовсе необязательна, достаточно экспертной оценки и поправочных коэффициентов от уровня рисков.
Чтобы реально ничего не упустить нужно собственно выполнить проектирование, и, скорее всего, сделать прототип. Но если заказчик эти работы не оплачивает, то это крайне большой риск. Увы. Я предпочитают продавить проекты с поэтапной оплатой, чтобы сделать прототип за счет заказчика. Тем более что прототип заказчику нужен также, как и мне, так что это win-win.
Если же вы знаете как реализовать проект, то детальная декомпозиция вовсе необязательна, достаточно экспертной оценки и поправочных коэффициентов от уровня рисков.
Не буду спорить. Если предметная область новая и требуется оценить работы из этой области, всегда велик риск ошибки. При этом системный подход с разбиением всего объема задач на конкретные такси все равно является правильным и позволяет сократить ошибки в оценках. При этом мы в этом случае во время оценки делаем дополнительное исследование проблемы. Человек, ответственный за оценку, советуется с другими разработчиками на тему правильности оценки. Но да — ошибиться можно всегда. Я лишь говорю, как можно уменьшить ошибки.
Касательно прототипа я тоже об этом писал. Любой крупный проект стоит делать поэтапно. При этом первый этап — прототип. И оценивать тогда уже каждый последующий этап. Вот так мы об этом говорим заказчикам: www.yumapos.com/#/services/custom
Мы делаем следующим образом: оцениваем весь проект (обычно 5000-30000 человеко часов). Первый этап прототип 500-5000 часов. При этом мы заранее говорим заказчику что мы хотим иметь возможность сократить или увеличить время и бюджет проекта после завершения прототипа. Но не более 25% от первоначального бюджета. Обычно заказчики соглашаются. Если же объем новых выявленных задач во время выполнения прототипа превышает 25%, то либо начинаем подрезать где-то, либо объясняем необходимость полного пересмотра бюджета. Иногда соглашаемся на 25% увеличения и все, если маржа и так достаточно большая.
Но все равно я абсолютно уверен, что системность подхода к оценке проекта или отдельного этапа увеличивает правильность оценки. Проверено на 1000+ случаях))
Касательно прототипа я тоже об этом писал. Любой крупный проект стоит делать поэтапно. При этом первый этап — прототип. И оценивать тогда уже каждый последующий этап. Вот так мы об этом говорим заказчикам: www.yumapos.com/#/services/custom
Мы делаем следующим образом: оцениваем весь проект (обычно 5000-30000 человеко часов). Первый этап прототип 500-5000 часов. При этом мы заранее говорим заказчику что мы хотим иметь возможность сократить или увеличить время и бюджет проекта после завершения прототипа. Но не более 25% от первоначального бюджета. Обычно заказчики соглашаются. Если же объем новых выявленных задач во время выполнения прототипа превышает 25%, то либо начинаем подрезать где-то, либо объясняем необходимость полного пересмотра бюджета. Иногда соглашаемся на 25% увеличения и все, если маржа и так достаточно большая.
Но все равно я абсолютно уверен, что системность подхода к оценке проекта или отдельного этапа увеличивает правильность оценки. Проверено на 1000+ случаях))
Я обычно продаю итерационную разработку и внедрение с малой длиной итерации. Это уменьшает риски заказчика — он может выйти раньше, если поймет что результат его категорически не устраивает. Это уменьшает мои риски, так как я получаю деньги раньше, у меня нету больших гэпов в cashflow. Это увеличивает удовлетворение заказчика, так как он видит работающую систему. Удовлетворение заказчика способствует продаже следующих этапов работ.
При этом не нужна точная оценка на большой промежуток времени, достаточно примерной с разбросом в 20%-30% и то можно скорректировать, так как заказчик сразу всю сумму не платит. А для оценки работ на пару недель-месяц можно просто и программиста спросить.
Вообще не понимаю откуда появилось такое стремление продавать большие проекты с огромной неопределённостью.
При этом не нужна точная оценка на большой промежуток времени, достаточно примерной с разбросом в 20%-30% и то можно скорректировать, так как заказчик сразу всю сумму не платит. А для оценки работ на пару недель-месяц можно просто и программиста спросить.
Вообще не понимаю откуда появилось такое стремление продавать большие проекты с огромной неопределённостью.
Не во всех отраслях это применимо. Увы.
В каких например? Ну кроме госов.
Бывают крупные внедрения/миграции enterprise-продуктов. Обычно такие проекты бьются на этапы, но этап может длиться несколько месяцев и стоить несколько миллионов.
Я делал крупные миграции и внедрения enterprise продуктов. Если за пару месяцев нечего показать, то зря заказчик связался с подрядчиком.
Сколько конкретно стоит — относительный вопрос. Если внедрение на 10 человек, то несколько миллионов это дорого, если на 10000, то несколько миллионов — ошибка округления в общих затратах.
Сколько конкретно стоит — относительный вопрос. Если внедрение на 10 человек, то несколько миллионов это дорого, если на 10000, то несколько миллионов — ошибка округления в общих затратах.
Медицина, банки да и госы бывают разные.
Медицина — госы, в основном, а в частных клиниках легко продать agile и поэтапную сдачу. Банки совсем разные бывают, я работал и госбанками с закупками по 93фз и с небольшими частными банками и не видел особых проблем с поэтапной оплатой и корректировкой scope, чтобы уложиться в фиксированную сумму.
Поддерживаю идею автоматизации процессов пресейла. Главное, в результате получить нечто большее, нежели красивую обертку над все теми же случайными цифрами.
Использование софта и оптимизация внутренних процессов делают маленькие, но уверенные шажки в сторону светлого будущего поддержки продаж, а уж если найти прием, который устоит против отечественного «лома» (цена раньше результатов аналитики), то сразу гигантский прыжок в мекку заказной разработки.
Кстати, буду рад, если отрекомендуете приложение, нацеленное на российский рынок.
Использование софта и оптимизация внутренних процессов делают маленькие, но уверенные шажки в сторону светлого будущего поддержки продаж, а уж если найти прием, который устоит против отечественного «лома» (цена раньше результатов аналитики), то сразу гигантский прыжок в мекку заказной разработки.
Кстати, буду рад, если отрекомендуете приложение, нацеленное на российский рынок.
Согласен. Мы пользуемся swproposal.com. Но есть еще evenflowpro.com, quoteroller.com. И еще несколько точно можно найти. Они все развиваются и полируются в плане функционала и требования заказчиков. Мы работаем для иностранного рынка, поэтому прекрасно подходит английский. Наверное со временем они локализуются. По крайней мере у нас в настройках есть выбор языка, но пока он там только один — английский.
А вам случаем не на мегамозг? Тематика статьи вроде не «хабравская». Или с песочницей еще непонятки…
Ход рассуждений понятный, но полезной информации в статье практически нет.
«Выстраивайте системную работу» (мышки, станьте ежиками.)
На какие именно этапы вы разбиваете процесс оценки?
Какие виды проектов вы ведёте в пределах «внедрения CRM»?
Каковы были хотя бы группы категорий, по которым велась оценка проекта?
Какой точности удалось добиться?
Для того, чтобы провести точную оценку, нужна коммуникация с заказчиком. Насколько выросло время на общение с ним?
«Выстраивайте системную работу» (мышки, станьте ежиками.)
На какие именно этапы вы разбиваете процесс оценки?
Какие виды проектов вы ведёте в пределах «внедрения CRM»?
Каковы были хотя бы группы категорий, по которым велась оценка проекта?
Какой точности удалось добиться?
Для того, чтобы провести точную оценку, нужна коммуникация с заказчиком. Насколько выросло время на общение с ним?
Спасибо за комментарий.
Мы занимаемся разработкой POS систем (www.yumapos.com). Каждая система, хоть и имеет общий функционал, уникальна и требует отдельного осмысления и последующей оценки трудозатрат. Средний разброс, как я писал выше, 5000-30000 часов. Последний раз я оценил систему в 27000 часов. И вот при оценке подобной системы мы не можем начать объяснять, что для того чтобы оценить нам нужно сделать прототип. Заказчик хочет сказать что ему надо и через несколько дней получить сроки и бюджет. Мы в этом случае, конечно, каждый раз работаем с более менее понятной для нас областью. Но размер проекта все равно требует усилий по детальной оценке. Скажем в последнем проекте, который я оценивал, было 29 модулей и еще 4 отдельным мобильных приложения с поддержкой четырех платформ (web, desktop, iOS, Android). Изначально показалось (как часто бывает), что проект максимум на 10000 часов. Но когда стал считать и прояснять мелочи получилось 27000.
Вот с чем я работаю. Я рассказал, чтобы Вы понимали мою ситуацию. У каждого она все таки индивидуальная.
Теперь отвечу на Ваши вопросы:
1. Мы разбиваем проект на этапы по следующим принципам
— первый этап — прототип, второй — создание базового функционала, третий и последующие — добавление и расширение функционала. При этом после выполнения прототипа мы корректируем все планы, чтобы они соответствовали всей имеющейся информации после создания прототипа. Корректируем бюджет и сроки.
— второй принцип заключается в том, что этапы я стараюсь разбивать не больше, чем 2-3 месяца работы, чтобы процесс оплаты протекал плавно.
— третий принцип — заказчик после каждого этапа должен видеть результаты работы. Рассказ, что мы написали всю серверную часть, которую не видно, потому что нет интерфейса не работает. Заказчик всегда хочет понимать за что он платит и так как он не программист чаще всего, лучше чтобы после каждого этапа были видимые результаты работы.
— четвертый принцип — задачи нужно разбивать настолько мелко, чтобы каждую можно было выполнить в пределах 1-10 часов.
2. Если Вы имеете в виду внедрение CRM типа MS Dinamix для заказчиков, то мы этим не занимаемся. Мы делаем проекты разработки с нуля, а также проекты когда мы разрабатываем часть Point of sale системы, а часть продаем готовые модули. Но чаще всего разработки с нуля не менее 50%. Если вопрос в том, какую CRM мы используем, то это тот функционал, что есть в swproposal.com. Она там не супер функциональная. Скорее простая. В основном мы храним информацию о клиенте и трекаем статус отношений с ним. Подгружаем файлы. На каждого клиента создаем проект и предложение или несколько предложений и также отслеживаем процесс переговоров по ним. Сразу извиняюсь, если я не совсем о том. До конца вопрос Ваш не понял.
3. Обычно мы разделяем объем работы на модули (например раздел Customers, Inventory, Orders liss). Далее делим на крупные задачи в рамках модуля (Customers groups management, customer form, и т.п.) и далее уже делим на мелкие задачи и подзадачи, чтобы каждая задача была 1-10 человеко часов. Если проект подразумевает этапы, то мы распределяем полученный лист задач на разные этапы.
4. Первоначально мы занимались разработкой всего, что могли найти. Были веб социальные проекты, мессенджеры, веб приложения для автоматизации бизнес процессов, CRM и много чего еще. Тогда мы начали работу по организации процесса оценки. Ранее оценивал просто программист на основании собственного опыта и собственной тщательности. Разные программисты давали сильно разные оценки и разную детализацию проекта. Однажды мы продали проект за 3 человеко-месяца, а делали около года. Сейчас ошибки бывают, но это не катастрофические ошибки и не выходят за пределы 20%. То, что мы сделали — заставили всех, кто участвует в продажах и оценке проектов действовать по утвержденным шагам с детализированной оценкой проекта. Так чтобы все большие задачи разбивались на логично взаимосвязанные маленькие с их последующей оценкой. Это сокращает вероятность ошибки.
5. Коммуникация, конечно, возросла. Но и возрос процент полученных проектов из тех, что мы оценивали подробно.
Мы занимаемся разработкой POS систем (www.yumapos.com). Каждая система, хоть и имеет общий функционал, уникальна и требует отдельного осмысления и последующей оценки трудозатрат. Средний разброс, как я писал выше, 5000-30000 часов. Последний раз я оценил систему в 27000 часов. И вот при оценке подобной системы мы не можем начать объяснять, что для того чтобы оценить нам нужно сделать прототип. Заказчик хочет сказать что ему надо и через несколько дней получить сроки и бюджет. Мы в этом случае, конечно, каждый раз работаем с более менее понятной для нас областью. Но размер проекта все равно требует усилий по детальной оценке. Скажем в последнем проекте, который я оценивал, было 29 модулей и еще 4 отдельным мобильных приложения с поддержкой четырех платформ (web, desktop, iOS, Android). Изначально показалось (как часто бывает), что проект максимум на 10000 часов. Но когда стал считать и прояснять мелочи получилось 27000.
Вот с чем я работаю. Я рассказал, чтобы Вы понимали мою ситуацию. У каждого она все таки индивидуальная.
Теперь отвечу на Ваши вопросы:
1. Мы разбиваем проект на этапы по следующим принципам
— первый этап — прототип, второй — создание базового функционала, третий и последующие — добавление и расширение функционала. При этом после выполнения прототипа мы корректируем все планы, чтобы они соответствовали всей имеющейся информации после создания прототипа. Корректируем бюджет и сроки.
— второй принцип заключается в том, что этапы я стараюсь разбивать не больше, чем 2-3 месяца работы, чтобы процесс оплаты протекал плавно.
— третий принцип — заказчик после каждого этапа должен видеть результаты работы. Рассказ, что мы написали всю серверную часть, которую не видно, потому что нет интерфейса не работает. Заказчик всегда хочет понимать за что он платит и так как он не программист чаще всего, лучше чтобы после каждого этапа были видимые результаты работы.
— четвертый принцип — задачи нужно разбивать настолько мелко, чтобы каждую можно было выполнить в пределах 1-10 часов.
2. Если Вы имеете в виду внедрение CRM типа MS Dinamix для заказчиков, то мы этим не занимаемся. Мы делаем проекты разработки с нуля, а также проекты когда мы разрабатываем часть Point of sale системы, а часть продаем готовые модули. Но чаще всего разработки с нуля не менее 50%. Если вопрос в том, какую CRM мы используем, то это тот функционал, что есть в swproposal.com. Она там не супер функциональная. Скорее простая. В основном мы храним информацию о клиенте и трекаем статус отношений с ним. Подгружаем файлы. На каждого клиента создаем проект и предложение или несколько предложений и также отслеживаем процесс переговоров по ним. Сразу извиняюсь, если я не совсем о том. До конца вопрос Ваш не понял.
3. Обычно мы разделяем объем работы на модули (например раздел Customers, Inventory, Orders liss). Далее делим на крупные задачи в рамках модуля (Customers groups management, customer form, и т.п.) и далее уже делим на мелкие задачи и подзадачи, чтобы каждая задача была 1-10 человеко часов. Если проект подразумевает этапы, то мы распределяем полученный лист задач на разные этапы.
4. Первоначально мы занимались разработкой всего, что могли найти. Были веб социальные проекты, мессенджеры, веб приложения для автоматизации бизнес процессов, CRM и много чего еще. Тогда мы начали работу по организации процесса оценки. Ранее оценивал просто программист на основании собственного опыта и собственной тщательности. Разные программисты давали сильно разные оценки и разную детализацию проекта. Однажды мы продали проект за 3 человеко-месяца, а делали около года. Сейчас ошибки бывают, но это не катастрофические ошибки и не выходят за пределы 20%. То, что мы сделали — заставили всех, кто участвует в продажах и оценке проектов действовать по утвержденным шагам с детализированной оценкой проекта. Так чтобы все большие задачи разбивались на логично взаимосвязанные маленькие с их последующей оценкой. Это сокращает вероятность ошибки.
5. Коммуникация, конечно, возросла. Но и возрос процент полученных проектов из тех, что мы оценивали подробно.
Спасибо за развёрнутый ответ.
1. Я спрашивал про этапы ОЦЕНКИ, которые вы упоминали в посте, а не этапы ПРОЕКТА. Принципы разбиения проекта отличные.
2. Мне не на что было ориентироваться, кроме названий блогов, куда вы запостили. Теперь я знаю вашу специализацию, а у меня как раз проект на эту тему начинается :)
3. Как делается оценка функциональности — понятно. А как вы работаете с требованиями к качеству — скорости, надёжности и т.д.? Как именно они влияют на оценку трудоёмкости у вас?
4. Супер, мой опыт тоже показывает, что при плохой оценке ошибка достигает 300%.
1. Я спрашивал про этапы ОЦЕНКИ, которые вы упоминали в посте, а не этапы ПРОЕКТА. Принципы разбиения проекта отличные.
2. Мне не на что было ориентироваться, кроме названий блогов, куда вы запостили. Теперь я знаю вашу специализацию, а у меня как раз проект на эту тему начинается :)
3. Как делается оценка функциональности — понятно. А как вы работаете с требованиями к качеству — скорости, надёжности и т.д.? Как именно они влияют на оценку трудоёмкости у вас?
4. Супер, мой опыт тоже показывает, что при плохой оценке ошибка достигает 300%.
Если говорить про POS то там ключевая задача состоит в обеспечении правильности расчетов чека. Там одновременно накладываются масса условий связанных с выбранным товаром, клиентом, существующими маркетинговыми компаниями и т.п. Для того чтобы этого добиться мы все подобные расчеты покрываем тестами (и клиентскую и серверную часть) и соответственно закладываем 50-100% времени на разработку тестов от времени разработки функциональности. В местах не критичных тестов пишем меньше или вообще не пишем. Но при оценке так и пишем скажем:
Task 1 — 50 man-hours
Sub task 1 — 10 man-hours
Sub task 2 — 10 man-hours
Sub task 3 — 10 man-hours
Unit tests — 15 man-hours
QA work — 5 man-hours
Раньше мы делали все это просто в excel но потом из-за частых ошибок перешли на приложение. Но принцип тот же самый.
Task 1 — 50 man-hours
Sub task 1 — 10 man-hours
Sub task 2 — 10 man-hours
Sub task 3 — 10 man-hours
Unit tests — 15 man-hours
QA work — 5 man-hours
Раньше мы делали все это просто в excel но потом из-за частых ошибок перешли на приложение. Но принцип тот же самый.
Мы подстроили процесс под функционал приложения. Получается так:
1. Продавец создает карточку проекта (связанную с его клиентом или не связанную) и загружает всю имеющуюся информацию. В последствии, если появляется что-то новое, то тоже добавляет туда в виде подгруженных файлов или комментариев.
2. Технический аналитик просматривает карточку проекта, анализирует всю имеющуюся информацию и либо формирует список вопросов, либо начинает работу над технической частью проекта. При этом иногда технический аналитик проясняет все напрямую с клиентом, а иногда через менеджера продаж.
(Сразу оговорюсь, что тут я говорю про предварительную максимально точную оценку. Оценку окончательную мы даем после прототипирования, как я и писал выше.)
3. В целом, когда информации достаточно, технический аналитик создает техническую часть предложения. Имеется в виду, что он фактически последовательно заполняет поле за полем от технической части с заголовками: «в чем цель проекта», «какие основные требования», «какие возможны риски», «какие основные модули можно выделить», «подгрузите картинку с архитектурой и опишите ее» (одну или много), «выберете технологии из списка», «укажите какие виды тестирования будут применяться», «как будет осуществляться коммуникация», «укажите документацию, которая будет предоставлена с проектом» и далее непосредственно необходимо заполнить таблицу «breakdown» где указать стадии, модули, такси и саб-таски с оценкой трудозатрат и необходимую категорию специалиста (software developer, senior software developer, project manager, QA engineer и т.п.). Далее технический аналитик планирует необходимое количество людей на стадию и сроки выполнения. Переносит отдельные задачи с одной стадии на другую. Описывает конкретный результаты после сдачи каждой стадии (если их больше одной). Когда техническая часть проекта завершена, технический аналитик ставит ее в статус «complete». Фактически количество трудозатрат и сроки проекта после этого уже определены.
4. Далее начинается ответственность менеджера продаж или человека ответственного за окончательную стоимость проекта. Менеджер продаж может просматривать техническую часть, но не может ее редактировать. Он же редактирует финансовую часть. Указывает стоимость за час, скидки, налоги (если надо) и получает общий бюджет проекта. Если продаются уже созданные части, которые имеют фиксированную цену, то добавляет их. Добавляет доп. услуги в духе обучения персонала, написание обучающей документации и т.п. Получив общую стоимость, он указывает условия оплаты включая расписание оплаты и способы перечисления денег. Плюс иногда добавляет 2-3 образца портфолио и референсов клиента, и генерит предложение. Соответственно, менеджер продаж тоже указывает статус финансовой части «complete» и после этого технический аналитик уже не может ничего менять в своей оценке.
5. Ну и часто этот процесс происходит в несколько циклов. Так как в процессе переговоров клиенту приходят в голову новые идеи или он что-то сокращает, удивив цену выше возможностей. Поступают новые требования и если они существенные мы создаем новое предложения на основе созданного, а если изменения не большие, то просто корректируем созданное предложение.
На вопрос 3 я все таки уже пытался ответить. В оценке каждой задачи у нас идет отдельная задача (или несколько) на написание текстов и работу QA инженера. То есть суммарные трудозатраты по задаче включают различные виды автоматического тестирования (для разных случаев применяются разные виды) и времени тестера. Само собой когда все оценивается техническим аналитиком он держит в уме требования к надежности и скорости системы. Исходя из этого и оценивает.
1. Продавец создает карточку проекта (связанную с его клиентом или не связанную) и загружает всю имеющуюся информацию. В последствии, если появляется что-то новое, то тоже добавляет туда в виде подгруженных файлов или комментариев.
2. Технический аналитик просматривает карточку проекта, анализирует всю имеющуюся информацию и либо формирует список вопросов, либо начинает работу над технической частью проекта. При этом иногда технический аналитик проясняет все напрямую с клиентом, а иногда через менеджера продаж.
(Сразу оговорюсь, что тут я говорю про предварительную максимально точную оценку. Оценку окончательную мы даем после прототипирования, как я и писал выше.)
3. В целом, когда информации достаточно, технический аналитик создает техническую часть предложения. Имеется в виду, что он фактически последовательно заполняет поле за полем от технической части с заголовками: «в чем цель проекта», «какие основные требования», «какие возможны риски», «какие основные модули можно выделить», «подгрузите картинку с архитектурой и опишите ее» (одну или много), «выберете технологии из списка», «укажите какие виды тестирования будут применяться», «как будет осуществляться коммуникация», «укажите документацию, которая будет предоставлена с проектом» и далее непосредственно необходимо заполнить таблицу «breakdown» где указать стадии, модули, такси и саб-таски с оценкой трудозатрат и необходимую категорию специалиста (software developer, senior software developer, project manager, QA engineer и т.п.). Далее технический аналитик планирует необходимое количество людей на стадию и сроки выполнения. Переносит отдельные задачи с одной стадии на другую. Описывает конкретный результаты после сдачи каждой стадии (если их больше одной). Когда техническая часть проекта завершена, технический аналитик ставит ее в статус «complete». Фактически количество трудозатрат и сроки проекта после этого уже определены.
4. Далее начинается ответственность менеджера продаж или человека ответственного за окончательную стоимость проекта. Менеджер продаж может просматривать техническую часть, но не может ее редактировать. Он же редактирует финансовую часть. Указывает стоимость за час, скидки, налоги (если надо) и получает общий бюджет проекта. Если продаются уже созданные части, которые имеют фиксированную цену, то добавляет их. Добавляет доп. услуги в духе обучения персонала, написание обучающей документации и т.п. Получив общую стоимость, он указывает условия оплаты включая расписание оплаты и способы перечисления денег. Плюс иногда добавляет 2-3 образца портфолио и референсов клиента, и генерит предложение. Соответственно, менеджер продаж тоже указывает статус финансовой части «complete» и после этого технический аналитик уже не может ничего менять в своей оценке.
5. Ну и часто этот процесс происходит в несколько циклов. Так как в процессе переговоров клиенту приходят в голову новые идеи или он что-то сокращает, удивив цену выше возможностей. Поступают новые требования и если они существенные мы создаем новое предложения на основе созданного, а если изменения не большие, то просто корректируем созданное предложение.
На вопрос 3 я все таки уже пытался ответить. В оценке каждой задачи у нас идет отдельная задача (или несколько) на написание текстов и работу QA инженера. То есть суммарные трудозатраты по задаче включают различные виды автоматического тестирования (для разных случаев применяются разные виды) и времени тестера. Само собой когда все оценивается техническим аналитиком он держит в уме требования к надежности и скорости системы. Исходя из этого и оценивает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка трудозатрат на проект и подготовка коммерческих предложений