Прочитал статью «Почему программисты ошибаются в оценке сроков?», которая вызвала у меня некоторое возмущение. К сожалению, не могу оставить комментарий, поэтому решил написать статью в песочницу.
Вообще-то, вопрос «Почему … ошибаются в оценке сроков?» применим к любой производственной деятельности. И вместо многоточия можно указать кого угодно (программисты, сантехники, плотники, слесари, кондитеры и т.д.). Этот вопрос является частью проблемы взаимодействия заказчика и исполнителя. Проблема возникает вокруг двух основных вопросов: «Сколько это будет стоить?» и «Как быстро вы это сделаете?». Эти вопросы стары как сама разумная жизнь и будут актуальными еще очень долго.
Самой важной характеристикой ответа на эти вопросы является точность, не минимальные сроки и цена, а именно точность, т.к. она определяет успешность проекта (работы, заказа и т.д.).
Автор приводит некоторый список причин ошибок, но этот список – это просто частные случаи. Если хорошо подумать, то можно найти еще множество причин. Но все они являются следствием отсутствия необходимого опыта и/или методик оценки трудоемкости.
В подтверждение этого предлагаю рассмотреть причины приведенные автором (плюс выводы, как повысить точность оценки):
1. Время чистое и грязное. Как и в любой отрасли, время на разработку определяется как временные затраты на подготовительно-заключительные мероприятия + время непосредственной работы + время на различные потери. Подготовительно-заключительное время можно оценить с помощью статистики, скорее всего оно будет примерно одинаковым для любой работы (отклонение 10-15%), время самой работы можно и необходимо прогнозировать (но об этом чуть позже), время на различные потери кажется самым сложным, но на самом деле тут все просто. Это время отлично коррелирует со временем на основную работу, но у каждой организации эта зависимость будет разной, т.к. она определяется на основе организационно-технического уровня организации. Соответственно, необходимо провести ряд исследований для подготовительно-заключительного времени и определить организационно-технический уровень компании, чтобы повысить точность оценки общего времени. Вывод: необходимо знание методик нормирования.
2. Производительность. Тут вообще нечего обсуждать, производительность должна быть константой, основная задача руководителя – следить за этим. Если производительность скачет, то это серьезный сигнал руководителю, вероятно, потенциальные возможности работников слишком завышены, и они (программисты) не соответствуют необходимому уровню. Кстати, именно поэтому на предприятиях вводятся различные квалификации (например, токарь третьего разряда), они показывают возможности работника и его производительность. Очень часто бывает, что производительность определяют по самому продуктивному сотруднику и потом применяют ко всем остальным, что не всегда правильно. Вывод: необходимо четко определять квалификацию, но и здесь без хорошего опыта не обойтись.
3. Исследования. Данная причина возникает только из-за отсутствия опыта или нехватки знаний. А еще появление такой причины говорит об отсутствии этапа проектирования, вот и приходится принимать проектные решения и заниматься исследованиями в процессе кодирования, естественно это увеличивает сроки разработки. А отсутствие этапа проектирования подтверждает отсутствие опыта у разработчика. Вывод: повышать опыт и квалификацию.
4. Сложные системы. Вот как раз здесь и требуются эксперты и/или методики оценки трудоемкости. С экспертами все понятно, а вот методику нужно подбирать (возможно, разрабатывать свою). Можно воспользоваться, например, COCOMO/COCOMO II или методом функциональных точек, но в любом случае, требуется умение ими пользоваться. Собственные наблюдения – чем сложнее система, тем менее точная оценка эксперта, а более эффективными и точными являются методики оценки. На небольших и несложных системах методики оценки дают слишком большую ошибку. Вывод: необходимы эксперты и методики оценки.
5. Исправление ошибок. Ошибки в процессе кодировании – это недоработки на стадии проектирования. Умение грамотно проектировать можно получить с опытом, либо в хорошем учебном заведении. Вывод: нужен опыт проектирования или хорошее образование.
6. Составные и нетиповые задачи. Автор говорит о том, что оценка таких задач основана на самоуверенности программиста. Это основная ошибка при оценке. Не знаешь, как подойти к задаче и точно оценить трудоемкость – не суетись, не опирайся на эмоции и интуицию, они здесь точно не помогут. Именно для таких ситуаций разработаны методики оценки. Вывод: необходимо знание методик оценки.
7. Оценка под давлением. А вот это уже проблема не программиста. И тут уже нужен не опыт разработок, а опыт переговоров, но он все равно нужен. Вывод: необходимо получать опыт переговоров.
Соответственно, ответ на первоначальный вопрос «Почему программисты ошибаются в оценке сроков?» очень прост. Программисты ошибаются потому, что не имеют необходимого опыта разработок и/или не умеют пользоваться методиками оценки трудоемкости разработки. А все остальное это следствия этих причин.
В целом статья отлично описывает современную ситуацию в web-индустрии. Новые web-программисты появляются как грибы после дождя. Опыт у таких разработчиков минимален, знания узкопрофильные, амбиции и самоуверенность завышенные. Все это в совокупности вынуждает их ошибаться в оценке сроков (трудоемкости), но, к сожалению, их ошибки портят репутацию всего сообщества программистов (и не только web). Поэтому, я думаю, не стоит ошибки новичков воспринимать, как проблему целой индустрии. И перед тем как задать вопрос программисту о сроках необходимо определить его опыт и знания. А это уже совсем другая история.
PS Я не претендую на абсолютную истинность всех моих рассуждений. Но, как я уже говорил, проблемы оценки трудоемкости имеются во всех сферах производственной деятельности. В научной школе «Моделирование сложных технических систем» мы почти 20 лет занимаемся различными вопросами в области трудоемкости, некоторые из них связаны с оценкой трудоемкости и основаны на теории конструктивно-технологической сложности. К сожалению, все наши работы ориентированы на машиностроение, но уверяю, в программной индустрии ситуация с оценкой трудоемкости абсолютно такая же. Два года назад я занялся проблемой оценки трудоемкости программных проектов, результатов еще никаких нет, пока идет процесс анализа и изучения текущей ситуации. На данный момент решается задача определения эффективности имеющихся методик и возможности применения элементов теории конструктивно-технологической сложности (мы называем ее теорией сложности) при оценке трудоемкости изготовления программных продуктов.
Суть теории сложности заключается в определении некоторого показателя, который дает количественную оценку сложности объекта. Затем на основе организационно-технического уровня предприятия определяется трудоемкость в конкретных производственных условиях. Далее описывать не буду, т.к. это совсем из другой области.
Автор: beevasya
Где-то, отчасти, Вы правы, как однако и автор статьи, вызвавшей Вашу критику. Основная проблема программистов – отсутствие или недостаточность этапа планирования. Но с другой стороны – задачи бывают разнотипные, и всего знать просто невозможно, учитывая ещё тот факт, что постоянно появляются новые технологии и программист теряет свою квалификацию менее чем за год.