Pull to refresh

Comments 15

отличная статья, мне очень понравилось, все по существу, только не описалась одна ситуация, когда заказчик хочет быстрее и готов доплатить, бред но и такое бывает.
«Девять женщин не родят одного ребёнка за месяц» :)
Отличный подбор ссылок в конце статьи, много полезного. Спасибо.
Смотришь с умилением на секцию «Проектирование решения». А что делать, когда ни менеджер, ни заказчик не хочет платить за проектирование и дизайн, как отдельную часть? И когда тест менеджер не знает, в принципе, что можно делать тестировщикам на этапе сбора требований? Конечно, это риторические вопросы… Реальная жизнь куда интересней, но нужно стремиться к идеалу :-)
Данная статья скорее относится к средним и крупным проектам. Поэтому без проектирования ничего не сделаешь и платить за это заказчику придется. Другой вопрос что проектировка и выполнение должным быть двумя отдельными задачами. И не факт что заказчик после выполнения проектировки (оценки) проекта захочет его осуществлять.
Отличная статья. Мне, как разработчику, интересно посмотреть что стоит за моими задачами.
Хочется сказать словами известной рекламы — «Вы еще делаете эстимейты? Тогда мы идем к вам!»

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

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

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

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

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

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

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

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

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

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

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