Как я могу оценить проекты, когда мне нужно включить кривую обучения для новых технологий?

Иногда существуют научно-исследовательские и опытно-конструкторские проекты, в которых ничего не известно заранее о технологиях, концепциях и клиенте. Тем не менее, менеджер по-прежнему нуждается в оценке времени. Что я могу сделать, чтобы получить полезные оценки?

Честно говоря, как пишет в своей книге «Черный лебедь» Нассим Николас Талеб: «Мы просто не можем предсказать». Главным образом из-за неизвестных неизвестных. Как правило, лучше сообщить этот факт, тот факт, что вы не можете предсказать, вместо того, чтобы сообщать оценку.

Как пишет Талеб: лучше быть в целом правильным, чем точно неправильным. Поэтому не забудьте сообщить о том, что вам сложно оценить, и использовать такие вещи, как «изучение кривых в новых технологиях» в качестве одного из аргументов. Это означает, что диапазон вашей оценки будет большим: «этот проект будет стоить от 100 до 500 тысяч».

Сказав это, тот, кто просит вас что-то оценить, понимает, что все не так просто.

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

Если вы используете инструмент параметрического моделирования, такой как SLIM или COCOMO (только Intermediate или Advanced, так как Basic не учитывает драйверы затрат), то должны быть поправочные коэффициенты для незнакомой технологии. Например, COCOMO имеет большое количество факторов , влияющих на стоимость , в том числе те, которые специально ориентированы на знакомство с целевой платформой, а также с языком и инструментами, используемыми для разработки системы. SLIM также учитывает общий опыт команды разработчиков, который должен учитывать особенности используемых инструментов и технологий.

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

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

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

Отделите основное время обучения и исследования от времени разработки. Разбейте проект на несколько подпроектов со счастливыми окончаниями. Убедитесь, что вы создали доказательство концепции после обучения.

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

Зависит от того, что я использовал FPA ( Function Point Analysis ) большую часть времени, но мы занимались этой «веб-разработкой для предпринимателей», я имею в виду, вы знаете, веб-компании Forbes 500.

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

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

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

Однако важны две вещи:

1. Каждый вид системы оценки должен иметь время калибровки для вашей организации. Вы никогда не разрабатываете в одиночку, по крайней мере, есть клиент, ожидающий вашего кода (или вы не будете так отчаянно от этого писать код для себя). Вопрос не в том, «как быстро он может развиваться?», А в том, «как быстро он может развиваться со всеми вами?»

2. Однажды у меня был менеджер, который читал этот роман о Черном лебеде и был без ума от него. Он говорил нам, что невозможно оценить, и я делал свои обычные точные оценки до + -10% неустанно ...

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

Извините, это совсем не помогает.

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

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