Оценка трудозатрат выполнения проекта по разработке ПО: практика в условиях украинской реальности

    Вступление



    К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
    Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
    Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
    В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
    В статье я описываю свой личный опыт оценки проектов, и,
    конечно же, у вас могли быть другие ситуации и свои методы и
    рекомендации оценивания.
    Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:
    • выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
    • и презентацию Сергея Бережного
      «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.

    Статья содержит такие разделы:


    • Украинские реалии при выполнении проекта
    • Проблемы и их решения
    • Подготовка к оценке
    • Перечень работ для оценивания
    • Оценка работ по написанию кода
    • Цифры и коэффициенты из практики
    • Пример расчета


    Украинские реалии при выполнении проекта


    На отечественном рынке преобладают проекты с фиксированной ценой (когда бюджет и сроки планируются заранее, при заключении договора). При оценке проекта, команда кроме стандартных рисков и проблем должна учитывать «современный и эффективный» подход заказчиков, которые, хотят совместить:
    • С одной стороны, получение точных оценок по бюджету и срокам до написания ТЗ, включение их в договор, и далее, при выполнении проекта, жесткий контроль этого бюджета и сроков.
    • Со второй — гибкость со стороны команды разработчиков, реализацию всех появляющийся по ходу проекта требований заказчика (т.к. заказчик часто до середины проекта сам не знает, чего хочет).
    • С третьей – несмотря на непонимание, того, что и как должно быть реализовано, нещадно «режут» задачи плана проекта (для уменьшения стоимости) в том числе и функции, которые все равно придется выполнять команде.

    При неудачном управлении проектом (если команда идет на поводу у заказчика) команда легко превышает сроки и бюджет, т.к. контракт подписан и бюджет согласован, далее работает в себе убыток.
    Понятно, что винить только заказчика во всем – неправильно. Нужно понимать, что оценка проекта часто проводится без достаточного анализа требований, недостаточно и неправильно расписываются задачи, и очень часто, в оценку включается только программирование, в недостаточном количестве учитывается тестирование и управление. При подписании контракта продавцы идут навстречу заказчику, снижая цену, а в ходе проекта недостаточно жестко отстаивает свою позицию команда (руководитель проекта в первую очередь, но в данном случае стоит говорить «команда», т.к. все участники должны быть нацелены на результат и в случае участник видит/предвидит проблему должен ее доносить руководителю).
    Кроме этого, есть еще один фактор – разнообразие проектов, систем и технологий, и недостаток квалифицированных специалистов. Это значит, что при планировании проекта архитектор или руководитель проекта могут не учесть, что могут в команду получить специалиста, который ранее не выполнял подобных задач или с специалиста с недостаточной квалификацией. Понятно, что в этом случае производительность будет ниже ожидаемой.
    Как же можно поступить в этой ситуации? Как оценить проект так, чтобы предполагаемые трудозатраты были достаточно точными?
    Для начала стоит рассмотреть проблемы и попытаться найти их решение.

    Проблемы и их решения


    1. Заказчик хочет знать точные цифры по стоимости и срокам проекта до подписания договора

    Решение:
    1.1. Выявить и сформулировать критерии приемки работ. Как это сделать? Посмотрите [1]. Суть в том, что нужно заказчику задать правильные вопросы: «Как вы узнаете, что проект успешен ?» и «Кто, кому и как будет сдавать систему?», а также у человека, который будет принимать решение получить ответ на вопрос «что нужно сделать, чтобы проект был принят»
    1.2. Выявить как можно больше требований и, самое главное, ограничений к проекту (т.е. не только функциональные, но и не функциональные требования)
    1.3. Протестировать требования. Если говорить более простым языком, требуется проверить, что написанные требования реалистичны, непротиворечивы, и сформулированы так, что можно однозначно проверить соответствует ли им решение. Опять же рекомендую посмотреть [1]
    1.4. Исходя из этого, расписать как можно детальнее перечень задач (смотрите дальше в статье)
    2. Заказчик хочет видеть более-менее детальный перечень работ, который при согласовании стоимости проекта, при первой же возможности режет самым неподходящими способами

    Решение:
    В плане работ важно выделять все задачи, а не только «видимые»
    Например, есть требования пользователей по просмотру определенных данных. Команда выявила, какие задачи нужно реализовать и оценила общий объем работ в 56 часов, разбив их таким образом:
    • Возможность просмотра всех записей – 8 часов
    • Возможность фильтрации по полю 1 – 8 часов
    • Возможность фильтрации по полю 2 – 8 часов
    • сортировка по полю 1 – 8 часов
    • сортировка по полю 2 – 8 часов
    • группировка по полю 1 – 8 часов
    • группировка по полю 2 – 8 часов

    Но в действительности под этими задачами есть базовая функциональность – создание таблиц в БД, хранимых процедур или представлений для выборки, создание бизнес-объектов, подключение их к модулю безопасности, подключение к модулю протоколирования, конфигурации и прочее.
    Что будет, если заказчик скажет: нет это слишком долго. Давайте уменьшать, и уберет задачи по группировке и сортировке(минус 32 часов). При этом продавцу, который обсуждает работы по проекту «крыть нечем». А с другой стороны за 24 часа весь объем в принципе не успеть.
    Поэтому я рекомендую выделить базовую функциональность, убрать которую можно только убрав всю задачу целиком. В данном примере — эта задача «Выборка данных из базы данных» занимает, допустим, 28 часов, а остальные задачи — по 4 часа.
    Это позволит при торгах более правильно вести себя продавцу, не подставляя к тому же команду. Убрав ненужные функции, все равно останется достаточное количество времени на разработки.
    3. Детальный анализ требований, написание ТЗ и более-менее четкая область работ по проекту происходит после подписания договора

    Решение:
    3.1. Выявить как можно больше требований и ограничений к проекту, которые требуется реализовать в системе и как каждое требование правильно сформулировать и проверить [1].
    3.2. Очень часто получается так, что пункты, которые заказчик убрал, все равно всплывают и их приходится делать, и поэтому, чтобы защитить себя, в договор, кроме плана проекта, нужно вносить и пункт ограничивающий рамки проекта. В него следует внести все пункты которые заказчик убрал из предлагаемого плана, а также другие пункты, которые команда видит и считает явно выходящими из рамок проекта. Все методологии разработки ПО акцентируют на это внимание. Фактически это может быть оформлено как приложение к договору или как часть технического задания.
    3.3. Очень важно определить работы, что должно быть выполнено силами заказчика. Это также требуется зафиксировать в договоре (приложении к договору, техническом задании) с указанием сроков выполнения
    4. Практически до середины проекта заказчик сам не знает, чего хочет (не говоря о стадии сбора требований)

    Решение:
    4.1. Включить временные рамки возможных изменений (т.е. на каких этапах изменения, в принципе, возможны)
    4.2. Запланировать периодические демонстрации (например, на этапах сбора требований и планирования – раз в неделю, на этапе разработки – раз в две недели ) в учитывать трудозатраты по их подготовке и проведению
    Демонстрации следует проводить не только для бизнес-заказчиков, но и для сотрудников других подразделений заказчика, потенциально вовлеченных в проект (системные администраторы, ключевые пользователи, служба безопасности и т.п.)
    Это позволит на ранних этапах получить замечания, обсудить проблемы, позволит пользователю привыкнуть к интерфейсу и функционалу
    5. Заказчик хочет, чтобы команда гибко подходила к его пожеланиям (изменения, дополнения) и реализовывала их в рамках проекта, а не в рамках последующих доработок, и при этом заказчик категорически ничего не хочет слышать про изменение бюджета проекта

    Решение:
    5.1. В план проекта явно включаем время на возможные изменения (закладываем буфер по срокам и по бюджету, вне заложенных рисков), которые по требованию заказчика будут потрачены на нужные ему изменения и доработки. Это, во-первых, дает возможности по работе над изменениями в рамках проекта, а во вторых заставляет заказчика вдумчиво относиться к запросам на изменение, т.к. этот ресурс уже явно ограничен
    5.2. Учесть возможность итерационного подхода к разработке и спланировать эти итерации. Учесть количество встреч, поставок, демонстраций и прочее.
    5.3. Как написано выше, в договор (как приложение к договору, или в техническое задание) включаем пункт, описывающий все то, что выходит за рамки проекта и от чего заказчик явно отказался.
    6. Заказчик хочет видеть множество документации по системе.

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

    Решение:
    8.1. Нужно закладывать в план определенное время на риски, которое команда может использовать по своему усмотрению

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

    С чего начать


    1. Как писал ранее, поймите, что нужно сделать, чтобы достигнуть цели проекта и сдать [1]
    2. Выявить как можно больше требований и ограничений к проекту. Не забудьте выявить требования к:
      a. Документации. Если вы не знаете, какая документация к ПО бывает – можно обратиться, например, к ГОСТ (ЕСПД) 19.101-77 «Виды программ и программных документов» [3] или спецификациям других методологий, и исходя из этого предложить заказчику перечень, из которого он сможет выбрать нужное
      b. Нефункциональным требованиям [4], которые, например, могут включать: локализацию, резервное копирование, мониторинг, протоколирование, безопасность, миграция данных, первоначальная заливка данных, требования к установке, требования к конфигурированию.
      Такую информацию можно получить у служб ИТ-поддержки заказчика и безопасности.
    3. Протестировать полученные требования [1]
    4. Как можно детальнее распишите перечень задач, так чтобы каждая задача имела вполне измеримые сроки выполнения. Например, на этапе оценки проекта задачи разбивать и оценивать можно до дня
    5. В оценке должны участвовать специалисты по разным направлениям: руководитель проекта, разработчик, тест-инженер, специалист по развертыванию и внедрению, специалист по удобству использования, специалист по управлению продуктом (product manager, им может быть то же аналитик)


    Перечень работ для оценивания


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

    • Встречи с заказчиком для проведения интервью и доклада о результатах
    • Написание документа требований
    • Тестирование требований
    • Написание и согласование договора и других инициирующих проект документов

    Проектирование решения

    • Написание ТЗ
    • Написание архитектуры решения
    • Тестирование ТЗ и архитектуры решения
    • Обучение специалистов предметной области
    • Установка сред разработки и тестирования
    • Написание тест-плана и вариантов тестирования системы
    • Встречи с заказчиком

    Разработка и внутреннее тестирование

    • Еженедельные встречи разработчиков
    • Программирование
    • Улучшение кода
    • Демонстрации (подготовка и проведение)
    • Первая установка решения на среду тестирования
    • Прохождение тест кейсов

    Тестирование на стороне заказчика

    • Первая установка в тестовую среду заказчика
    • Поставки бета версий
    • Доработка и исправление неисправностей

    Внедрение

    • Установка на рабочий сервер
    • Обучение пользователей
    • Написание инструкций

    Дополнительно

    • Время на риски
    • Время на изменения
    • Управление проектом

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

    Оценка работ по написанию кода


    Для оценки работ по разработки рекомендую придерживаться таких правил:

    * Для достижения цели проекта разбейте ее на пользовательские действия (User stories), которые разбейте на задачи, которые в свою очередь на подзадачи и т.д. И так до тех пор, пока каждая задача станет понятной человеку уровня младший специалист (Junior Developer), и будет иметь четкие критерии, как проверить ее реализацию

    * Не забывайте выделять базовые задачи, которые нельзя исключать
    Не забудьте учесть такие задачи:

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

    Цифры и коэффициенты из практики


    • Для введения в проект нового человека и установку ему среды разработки, запланируйте не менее 40 часов (1 неделя)
    • Еженедельные встречи разработчиков – 4 часа каждую неделю для каждого разработчика
    • Первичная установка решения на тестовый сервер – запланируйте 80 часов (2 недели)
    • Для подготовки каждой демонстрации – 8 часов (время которое требуется архитектору для сборки и проверки модулей перед демонстраций; 8 часов если в проекте 3 разработчика, если разработчиков больше – то аналогично увеличиваем)
    • Встречи (демонстрации) с заказчиком – каждая встреча по 4 часа (на встречу по моему опыту лучше ездить троим: руководитель проекта, архитектор, аналитик или специалист по тестированию)
    • Первая установка в тестовую среду заказчика – 40 часов
    • Первая установка в рабочую среду заказчика – 40 часов
    • Подготовка и отправка каждой поставки – 8 часов (это включает компиляция, упаковка, написание процесса установки, помощь в установке)
    • Доработка и исправление неисправностей (refactoring) – 25% от разработки
    • Задачи по тестированию 30-50% от времени, потраченного на разработку (разработку документа требований, разработку ТЗ, функционала и прочее)
    • Время на риски – по крайней мере, 10% от общего времени
    • Время на изменения – по крайней мере, 10% от общего времени
    • Управление проектом – 15% от всего времени проекта
    • Доработка и исправление неисправностей – 25% от времени на разработку
    • Аналитик в среднем создает 3 страницы утвержденной документации в день

    Пример расчета


    Допустим, в результате оценки получились некоторые цифры
    • Проанализировав задачи на разработку (включая проектирование) у нас получилось 1200 человеко-часов.
      Принимаем решение, что задачи по разработке будут вести 3 разработчика. Тогда работы по разработке будут занимать 10 недель.
    • Требуется писать и согласовывать много документации, включающее требования, ТЗ, архитектуру решения, инструкции пользователям и прочее. Общий полезный объем на выходе – 400 страниц
    • Приложение имеет сложную бизнес-логику, поэтому тестирования много (поэтому берем 40% от разработки)
    • Планируем 5 встреч с заказчиком для выявления требований
    • Планируем 3 встречи с заказчиком для согласования видения и проекта решения
    • Планируем 4 демонстрации продукта заказчику на этапе разработки
    • Планируем 10 поставок на тестовую среду заказчика


    Исходя из этого, принимаем решение, что для данной оценки будем ориентироваться на следующий состав команды:
    • 3 разработчика
    • 1 тест инженер
    • 1 бизнес — аналитик
    • 1 системный аналитик (архитектор, он же будет выполнять инфраструктурные задачи)
    • 1 руководитель проекта

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


    Роли


    Количество человек


    Время


    Всего


    Этап анализа и сбора требований

     
     
     
     
    • Встречи с заказчиком для проведения интервью и доклада о результатах

    Руководитель, аналитик, архитектор

    3

    5раз х 4часа

    60

    • Написание документа требований

    Аналитик, архитектор

      
      
      
    • Тестирование требований

    тест инженер

     
     
     
    • Написание и согласование договора и других инициирующих проект документов

    Руководитель проекта

    1

     
     
    Проектирование решения

     
     
     
     
    • Написание ТЗ

    Аналитик, архитектор

     
     
     
    • Написание архитектуры решения

    архитектор

    1

    40

    40

    • Тестирование ТЗ и архитектуры решения

    тест инженер

     
     
     
    • Обучение специалистов предметной области

    Все

    7

    40

    280

    • Установка сред разработки

    Архитектор, разработчики

    4

    16

    64

    • Установка среды тестирования

    тест инженер или архитектор

    1

    40

    40

    • Написание тест-плана и вариантов тестирования системы

    тест инженер

     
     
     
    • Встречи с заказчиком

    Руководитель, аналитик, архитектор

    3

    3 раза х 4часа

    36

    Разработка и внутреннее тестирование

     
     
     
     
    • Еженедельные встречи разработчиков

    Архитектор, разработчики

    4

    10 встреч по 4 часа

    160

    • Программирование

    Разработчики

    3

    400

    1200

    • Улучшение кода

    архитектор

    1

    3 х 100

    300

    • Подготовка демонстрации

    архитектор

    1

    4 демонстрации по 8 часов

    32

    • Проведение демонстрации

    Архитектор, руководитель проекта, аналитик

    3

    3 х 4

    36

    • Задачи тест инженера (прохождение тест кейсов), 40% от разработки

    тест инженер

    1

     
    480

    • Первая установка решения в среду тестирования

    специалист по тестированию или архитектор

    1

    80

    80

    Тестирование на стороне заказчика

     
     
     
     
    • Первая установка в тестовую среду заказчика

    архитектор

    1

     
    40

    • Поставки бета версий

    архитектор

    1

    10 поставок по 8 часов

    80

    • Доработка и исправление неисправностей (25% от разработки)

    Разработчики

    2

     
    300

    Внедрение

     
     
     
     
    • Установка на рабочий сервер

    архитектор

     
     
    40

    • Обучение пользователей (допустим 3 обучения по 4 часа)

    Аналитик

    1

    3 х 4

    12

    • Написание инструкций

    Аналитик

     
     
     
    • Написание документации

    Часть аналитик, часть архитектор

     
    135 дней по 3 страницы

    1080

    • Тестирование документации

    Тест инженер

     
    30% от ее написания

    320

    Итого


     


     


     


    4680


    Дополнительно

     
     
     
     
    • Время на риски

     
     
    10% от разработки

    120

    • Время на изменения

     
     
    10% от разработки

    120

    • Управление проектом

    Руководитель проекта

     
    15% от проекта

    700

    Всего


      


    Приблизительно 5620 часов



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

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

    Заключение


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

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

    Что можно посмотреть еще по теме? Смотрите раздел ссылки.

    Ссылки


    1. Сергей Мартыненко «Написание тестов, как вид тестирования требований» http://vimeo.com/13803733

    2. Сергей Бережной «My Story: «Путь овертаймов»

    3. ГОСТ (ЕСПД) 19.101-77 «Виды программ и программных документов» http://www.rugost.com/index.php?option=com_content&task=view&id=48&Itemid=50

    4. Наталья Желнова. Нефункциональные требования к ПО: как их определять и откуда брать цифры
    akiselev87.wordpress.com/2011/07/14/наталья-желнова-нефункциональные-тр
    5. С. Архипенков “Оценка трудоемкости и сроков разработки ПО” http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf

    6. Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения http://leopard.in.ua/2010/03/22/desyat-smertnyx-grexov-v-ocenke-trudoyomkosti-razrabotki-programmnogo-obespecheniya/

    7. Михаил Острогорский «Подход к оценке сроков создания технической документации» http://www.philosoft.ru/metrics-idea.zhtml

    8. Сергей Поволяшко «Трудозатраты и планирование при тестировании» http://qaclub.com.ua/wp-content/uploads/d/qaclub6_19-02-10/QAClub_TestEffortsPlanning.pdf
    Инфопульс Украина 166,77
    Creating Value, Delivering Excellence
    Поделиться публикацией
    Похожие публикации
    Комментарии 15
    • +1
      отличная статья, мне очень понравилось, все по существу, только не описалась одна ситуация, когда заказчик хочет быстрее и готов доплатить, бред но и такое бывает.
      • 0
        «Девять женщин не родят одного ребёнка за месяц» :)
      • +1
        Отличный подбор ссылок в конце статьи, много полезного. Спасибо.
        • +1
          Смотришь с умилением на секцию «Проектирование решения». А что делать, когда ни менеджер, ни заказчик не хочет платить за проектирование и дизайн, как отдельную часть? И когда тест менеджер не знает, в принципе, что можно делать тестировщикам на этапе сбора требований? Конечно, это риторические вопросы… Реальная жизнь куда интересней, но нужно стремиться к идеалу :-)
          • 0
            Данная статья скорее относится к средним и крупным проектам. Поэтому без проектирования ничего не сделаешь и платить за это заказчику придется. Другой вопрос что проектировка и выполнение должным быть двумя отдельными задачами. И не факт что заказчик после выполнения проектировки (оценки) проекта захочет его осуществлять.
          • +1
            Отличная статья. Мне, как разработчику, интересно посмотреть что стоит за моими задачами.
            • +1
              Хочется сказать словами известной рекламы — «Вы еще делаете эстимейты? Тогда мы идем к вам!»

              1. Заказчик хочет знать точные цифры по стоимости и срокам проекта до подписания договора
              перевожу — а) заказчику придется переплатить 1000 часов для того чтобы иметь ложную уверенность, что он знает, во сколько обойдется его проект. На практике же:
              б) Есть серьезный шанс, что получив такую оценку, заказчик откажется от проекта. Тогда эти десятки а то и сотни часов на оценку проекта будут потрачены впустую
              в) если заказчик не откажется, то каков собственно смысл тратить время на оценку проекта? Лучше стартонуть на пару недель раньше.
              г) в начале проекта будет казаться, что времени еще много, и все будут пинать. В конце проекта окажется, что хотя формально все задачи на 99% выполнены, последние проценты будут занимать не часы а недели. Особенно ухудшает ситуацию, если на повестке дня есть требования к производительности.

              2. Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много.
              Либо вы используете устаревшие технологии, либо вы вообще не умеете работать/работаете командой без опыта совместной работы. Возможно, в каждом проекте кардинально меняется предметная область и технологии.

              ну а вообще тут, конечно, куча книг написана на эту тему… Люди, забудьте о оценках проектов в часах — выиграют ВСЕ.
              Оцените фичи по сложности (1-2-3), расставьте вместе с клиентом в порядке важности и последовательности, давайте ему попробовать результат каждые две недели. Через два месяца окажется, что то что казалось важным, можно сделать через год. А функция, о которой даже не думали, и определит успех проекта.
              • +1
                как сообщить себе или заказчику конечную цифру: сколько нужно месяцев на проект и денег, если не приравнивать сложность фичи в единицах к ожидаемым времязатратам? Ну оценил я фичу 1 в 10$, 2 — в 20$ А сколько времени нужно на неё?
                • +1
                  Точно — никак.
                  Заказчик крайне редко может вам рассказать полностью какой именно проект ему нужен.

                  Так зачем же строить иллюзии и тратить на это деньги? Примерный ориентир (1-2 месяц, 3-6, 6-9), если задача вам по плечу, можно назвать практически сразу, а вот в процессе работы все будет меняться.

                  Это не покупка мерседес, где все просчитано и стоимость каждой опции строго определена заранее. Но там кстати список опций будет предопределен и что-то добавить в него будет затруднительно.
                • +1
                  Если заказчик по каким-то причинам уже решил, что будет работать с вами — то всё хорошо. Это значит, у него есть к вам доверие. Тогда можно убедить, что для него самого оплачивать часы фактической работы лучше, чем фиксед прайс с заложенными рисками и бюрократией при попытках что-то поменять в проекте.

                  А если у него доверия к вам нет — работаете первый раз? «Я буду оплачивать часы, а они будут балду пинать, в чем их заинтересованность сделать быстрее?».
                  А если заказчик в поиске среди нескольких исполнителей — то вот тут будут сложности. Цена проекта здесь для него — сравнительная характеристика. И если 3 команды готовы «сказать цену», а вы — убеждаете работать по-другому, то не факт, что он вообще захочет слушать вашу аргументацию :)

                  Можно сказать — ну и не работайте с такими заказчиками. Так сказать можно, если потенциальных заказов у вас миллион. А если нет?

                  Статья хороша хотя бы тем, что в ней есть конкретные цифры, от которых можно оттолкнуться, когда оценивать всё-таки приходится.
                  И как раз на небольших проектах, где «примерный ориентир» в 1-2 месяца вроде бы очевиден, расчеты помогут не забыть включить/обдумать тестирования и поставку отдельно.
                • +4
                  Добрый день (доброй ночи).
                  Ребята, большое спасибо за то, что дочитали статью (эти многа букв и совсем мало картинок) до конца и за комментарии, которые оставили. Я специально не отвечал на каждый конкрентый комментарий, для того, чтобы ответить на все замечаения и предложения сразу.
                  Как по мне, данное направление (роль архитектора решения) до сих пор освещается очень плохо (по сравнению с разработкой, тестированием, аналитикой, руководством проектами) и поэтому хотелось написать статью, которая хотябы побудит поделиться опытом тех у кого он есть, и поднять эту тему на обсуждение.
                  Отвечая на вопросы еще раз замечу, что:
                  Во-первых, рассматривает проекты с фиксированной стоимостью и ни о какой итерационной методологии (типа скрам) и постоянного раскручивания заказчика на деньги тут речи не идет – вот это и особеность наших заказчиков. Идея заключается в другом: при оценке проекта сразу заложить и донести до заказчика число итераций и возможные модификации. Это сразу обезопасит вас и повысит ответственность заказчика.
                  Во-вторых, по сути – это внутренние оценки, и совсем не все обязательно их в таком виде показывать заказчику. Действительно, за половину работ, которые я узакал, заказчик платить не хочет и не собирается, но вы, внутри команды, компании должны понимать в какие трудозатраты выльется данный проект, т.к. эти работы все равно делать нужно. А заказчику можно показывается другой план, написанный на бизнес-языке, который он понимает и воспринимает.
                  В третьих, эта статья не является:
                  • Оценкой сроков проекта
                  • Оценкой стоимости проекта
                  • Руководством для продавцов проектов
                  Кроме того, часть замечаний к статье относится к руководству проектом, а не к его оценке. А это совсем другая тема.
                  В четвертых, на аналитику не обязательно тратить недели, для того, чтобы сделать оценки. Достаточно провести несколько встреч с бизнес-пользователями, с отделом безопасности и ИТ, для того, чтобы понять объем работ и решить интересно это заказчику и вам или нет. Зачем подписываться на убыточный проект? И получать убытки и гробить команду?
                  • +2
                    К статье сделал некоторые измения. Похоже скрывались пункты статьи, в которых были вложенные списки. Неправильно отображалась таблица — не показывались работы. И по тексту также не все кусочки, включающие вложенные списки также скрывались.

                    Относительно коментария: «Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много»

                    Это не совсем так. Скорее всего вы не увидели, т.к. таблица отображалась не правильно.
                    60 часов — это только на встречи, но есть и написание документации, которое сведено в один пункт внизу таблицы. Допустим на первом этапе сбор требований (и другие бумажные работы ) — пятая часть работ по созданию документации — а это (1080 + 320)/5 = 280 часов. Т.е. на этапе анализа и сбора требований будет потрачено 340 часов.
                    И понятно будут и другие работы — написание ТЗ и архитектуры решения.

                    Прошу прощения за то, что не вычитал статью после публикации.
                    • 0
                      Касательно документации на примере автоматизации учета: все заказчики на стадии предпроектной подготовки говорят о том что хотят видеть бумажное описание всех реализованных функций, методички по работе для каждого сотрудника и т.п. Но по окончанию проекта их интересует только то, чтобы каждый сотрудник заказчика работал и выполнял свою работу. Из чего следует что проект принимается без должной документации, но с обученным персоналом.
                      И оказывается что важнее найти общий язык с ключевыми сотрудниками заказчика, обучить их (чтобы они обучили остальных), чем выписывать килограммы документации.
                      • 0
                        И большое спасибо за статью. Очень структурировано.
                        ВСЕМ: Перечитывать перед каждым новым проектом.
                    • 0
                      В плане непонятно как аналитик будет работать больше полугода при продолжительности проекта в 4.5 месяца (при 100% загрузке всех). ИМХО, он — узкое место, и при таком объёме документации их нужно садить двое.

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

                      Самое читаемое