Как оценивать задачи программисту 1С

11.08.16

Архитектура

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

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

Сразу оговорюсь, у меня до сих пор не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, и только о технической оценке. Иногда по "политическим" мотивам техническую оценку необходимо уменьшить или увеличить, но данный вопрос не будем рассматривать. Также в статье не рассматривается вопрос торгов по оценке и переоценка в процессе выполнения задачи.
В нашей работе приходиться оценивать задачи с некоторыми неизвестными факторами. Чем их больше, тем больше мозг "бунтует" и сопротивляется решению вопроса.  Обычно сопротивление мозга проявляется в беспокойстве, страхах, т.к. с одной стороны возникает страх завысить оценку и показаться некомпетентным или остаться без задачи или даже без клиента, с другой стороны страшно не учесть "подводных камней" и в будущем сидеть часами, а то и днями, делая неоплачиваемую работу.

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

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

Хорошей оценкой в этой статье будет считаться ясная и комфортная оценка для исполнителя.

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

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

Когда мне говорят, что не могут оценить задачу даже вилкой, я обычно сначала уточняю: "За миллион часов сделаешь?". На что чаще всего получаю утвердительный ответ и сомнение в моей адекватности. После того как с "небом" мы определились, стоит определиться с "землёй". Следующий вопрос: "А за два часа?". На этот вопрос получаю предсказуемое "Нет", т.к. в противном случае ко мне не обратились бы за помощью. Далее играя в "больше, меньше", разрыв сокращается и получается вилка, которую назовём первичной.

Для примера, попытаемся оценить задачу "Надо разработать обработку загрузки поступлений товаров и услуг в 1С:Бухгалтерию предприятия из xml файлов, выгруженных из другой программы". В текущей постановке (а именно так чаще всего приходят задачи от заказчика) совершенно не ясно, сколько это будет стоить, но первичную вилку сможет дать практически любой программист, знакомый с 1С:Бухгалтерией предприятия. Она будет скажем: от 6 до 100 часов. Это уже что-то.

С нижней оценкой всё понятно - она рассчитана методом "если повезет".

А как возникает верхняя граница оценки? Выясняется, что верхняя граница возникает из-за того, что исполнитель, например, толком не понимает, что делать, или из-за того, что заказчик ранее постоянно уточнял свои требования к интерфейсу по уже оцененной и выполненной задаче. Конкретных причин верхней оценки может быть много, но самая главная: "непонимание, что нужно делать".

Если непонимание связано с тем, что вы никогда не работали с ЗУП, а задача "сделать так, чтобы расчетные листки формировались корректно", то первое, о чём стоит подумать – это отказ от данной задачи. Если в силу определенных обстоятельств отказ практически невозможен, будьте готовы, что комфортную оценку вы не получите, и это неплохо, т.к. опыт тоже дорого стоит. Чтобы минимизировать риски, обращайтесь за помощью к тем, кто имел опыт решения подобных задач. Остальные причины верхних границ нужно прописывать в конкретных требованиях или ограничениях, а также снимать риски вопросами.

С ограничениями всё просто. На моей практике заказчик всегда адекватно относился к большому перечню ограничений. Накапливайте свой перечень ограничений от каждой задачи, т.к. зачастую в разных задачах одни и те же риски.  В примере с загрузкой из xml, в оценку можно включить разработку обработки, написание инструкции, а в ограничениях прописать, что в оценку не входят: консультации пользователей по работе с обработкой; настройка ролей и интерфейсов; доработка в связи с изменениями конфигурации заказчиком или третьей стороной; доработка из-за изменения формата xml.

Задать вопросы и запросить дополнительные детали сложнее. Здесь опять появляется опасение показаться некомпетентным. Порой совершенно безобидный вопрос расценивается как отсутствие знаний. Постарайтесь перебороть этот страх. Вопросы задавать можно и нужно.

Один из самых высококвалифицированных программистов, с которым мне посчастливилось работать, начинал задавать самые простые вопросы, когда у него появлялась новая задача. Как правило, его собеседник сперва снисходительно отвечал на явно пустяковые вопросы, но чем дальше, тем больше понимал, как много для него самого неясностей. Рассказывали случай, как целый отдел методологов крупной компании взял паузу на неделю, чтобы ответить на вопрос, поставленный этим программистом. Фиксируйте все ответы, даже неадекватные ответы.

Например, если в шаблоне и примере данных нет необходимых для загрузки договоров полей, на вопросы "Есть ли данные по договору в другой учетной системе, аналоге документа поступления? Могут ли специалисты другой учетной системы дополнительно выгрузить номер и дату договора?", вам может быть дан ответ "Мы не программисты и этого не знаем". Для вас это означает, что оценку можно аргументированно повысить, так как дополнительно, с помощью заказчика (это отдельно прописать) предстоит анализ и общение со специалистами другой учетной системы.

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

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

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

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

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

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

Подзадачи для нашего примера:

  1. Согласование с разработчиками другой учетной системы (через заказчика) полей поиска элементов справочника "Договоры контрагентов" и изменение формата выгрузки: 2 - 8 часов
  2. Утверждение формата выгрузки из другой учетной системы - 0 часов (работа заказчика)
  3. Разработка функционала для сопоставления текущих договоров с полями, выгруженными из другой учетной системы - 0 - 8 часов.
  4. Сопоставление договоров 1С и кодов другой учетной системы - 0 часов (работа заказчика)
  5. Подготовка шаблона Excel для ручного заполнения соответствий кодов другой учетной системы и номенклатуры (иерархически): 2 часа
  6. Сопоставление номенклатуры 1С и кодов другой учетной системы - 0 часов (работа заказчика)
  7. Загрузка значений дополнительного свойства "Код другой учетной системы" справочника "Номенклатура" из Excel: 2 - 4 часа
  8. Разработка алгоритма создания элементов справочника "Номенклатура" по коду другой учетной системы и наименованию: 2 часа
  9. Разработка обработки загрузки поступлений товаров и услуг из xml: 8 - 12 часов
  10. Разработка регламентного задания (для автоматического запуска по расписанию) - 2 часа
  11. Подготовка инструкции (по настройке расписания и запуску обработки) - 4 часа
  12. Составление контрольных примеров (один документ на каждый пример), подготовка тестовой среды: поступление без НДС, поступление с НДС 18%, поступление с ошибкой по контрагенту (не найден по ИНН/КПП), поступление с созданием новой номенклатуры: 2 - 3 часа

Тестирование обработки согласно контрольным примерам, составление протокола тестирования: 4 часа


После того как будут получены ответы на вопросы, прописаны конкретные требования и ограничения, а также задача будет разложена по подзадачам - вилка оценки скорее всего будет приемлемой. В нашем примере: 28 - 49 часов. 
Не надо бояться, если вилка по прежнему с большим разбросом, главное, что вы сами понимаете причину разброса и можете её аргументировать.
Если заказчик настаивает на четкой оценке, выставляйте верхнюю границу. Страхи исчезнут сами, т.к. на любой вопрос по оценке вы будете готовы предоставить аргументы.

Итак, выдержка по оценки задач:
1. Прикиньте максимум и минимум затрат. Неважно, что оценки могут отличаться в разы
2. Задавайте вопросы, фиксируйте ответы
3. Прописывайте ограничения
4. Прописывайте конкретные требования
5. Разделите задачу на подзадачи
6. Скорректируйте первоначальную вилку, не стремитесь, чтобы она обязательно была узкой. Стремитесь к тому, чтобы любой пункт оценки вы смогли аргументировать
7. Не бойтесь ошибаться в оценке, если задачу целесообразно решить по отличным от "меркантильных" мотивам


Тем, кому интересно изучить данный вопрос подробнее, советую почитать книгу Стива Макконнелла "Сколько стоит программный проект".

программист 1С задачи вопросы оценка

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1386    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

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

11.12.2023    1598    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3751    0    ivanov660    10    

28

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1784    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2837    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9517    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1352    0    Ingraf    0    

14
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Petr54-ru 90 11.08.16 19:25 Сейчас в теме
Есть три вида принципиально разных по объему задач:
1. Те, задачи которые делаются за пару часов;
2. Те проекты, которые делаются за выходные;
3. И те проекты, которые не делаются за выходные.

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

В умных книжках подробно описаны масса различных методологий разработки, тысячи их, практически все методики предлагают рабочие методики оценки трудоемкости, бери подходящие по задачам и команде методики, пользуйся, какие проблемы?
DarkAn; Sure; AlenaR; NatalkaBal; mike_grig; bulpi; Paradise.87; EliasShy; kuntashov; Светлый ум; +10 1 Ответить
2. SamBadi 209 11.08.16 22:49 Сейчас в теме
(1) Petr54-ru, отчасти согласен, что от объема задачи напрямую зависит методика оценки.
Но какая-та градация у Вас выборочная, если придраться к вашей формулировке, то проект на неделю и на 5 лет находятся в одном "мире задач", а это не так.
Отвечаю на ваш вопрос: проблема в том, что тысяча книг написано, а коллеги разработчики, все равно избегают браться за задачу когда их просишь предварительно оценить, потому что, испытывают дискомфорт из-за возможности ошибиться. Пусть это будет тысяча первая статья, но если кому-то она поможет не отказаться от задачи и сделать её не себе в убыток, то цель достигнута.
abasovit; Spacer; Artem-B; Olenevod; Nelli_A86; RustIG; +6 Ответить
5. Petr54-ru 90 12.08.16 06:08 Сейчас в теме
(2)

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

В этом месте есть проблема, которая в основном обусловлена нашей 1С-ной спецификой. Если на стороне заказчика есть ИТ-специалисты, способные предоставить разработчикам внятное техзадание, то все хорошо. Обычно на стороне заказчика таких людей нету. Можно провести анализ, написать и согласовать рабочее техзадание, а заказчик возьмет это ТЗ, скажет спасибо и без проблем найдет разработчика, который за небольшие деньги по готовому техзаданию сделает все, что нужно. Можно пойти по пути, что сделать первую часть проекта "предпроектные работы" - исследование, сбор требований, проектирование, согласование - а на выходе будет согласованное ТЗ, за который заказчик заплатил и с которым заказчик может пойти к любому исполнителю. С другой стороны, заказчик может стоять на позиции, что ему не нужно техзадание, ему нужно решение проблемы и за всякие левые бумажки он платить не будет. И тогда самый разумный подход - нарезать большую задачу на "микропроектики" из серии - "мы это сделаем за выходные + " в которых объединять логически связанные сценарии использования (use cases), чтобы можно было спокойно, на основании своих экспертных оценок выводить трудоемкость работы, сроки сдачи и стоимость, далее умножать эти показатели на два и выставлять заказчику. Если ожидания заказчика существенно ниже наших рассчетов - то либо заказчик изменит свои ожидания, либо это просто не наш заказчик.

Тут, относительно трудоемкости важно понимать две вещи:
1. Производительность двух программистов с одинаковым по времени опытом работы может отличаться в разы.
2. У программиста может быть в загашничке старая разработка которая с минимальными затратами может быть адаптирована под новую задачу (тот самый reuse).
AlenaR; lina_00; sevushka; Sup4ik; premierex; sulfur17; teflon; SamBadi; Dem1urg; +9 Ответить
55. DarkAn 1078 12.11.20 11:45 Сейчас в теме
(5) А еще у программиста, могут быть "критические дни", когда вообще есть апатия к работе и мысли не идут и задачи не клеятся.
Swamt; galago; +2 Ответить
3. starik-2005 3031 11.08.16 23:04 Сейчас в теме
В методологии SCRUM для оценки задач для спринта используется технология покера планирования, когда независимо друг от друга разработчики оценивают задачу, а потом тех, кто дал экстремальные оценки, спрашивают, почему. В итоге таким образом рождается вполне реальная оценка, которая, исходя из практики применения данного подхода, оказывается куда точнее, чем обычная оценка.
maksa2005; FB_2034913123237402; dj_serega; Kserken; rpgshnik; dimadeev; necropunk; SamBadi; zhyhallo; Mi4man; miavolas; shalimski; +12 1 Ответить
4. dmt 66 12.08.16 04:59 Сейчас в теме
Понравилось. Невнятные пожелания преобразуются в четкие требования.

(3) starik-2005, это когда есть ТЗ или внятные требования. А когда нет?
7. SamBadi 209 12.08.16 10:46 Сейчас в теме
(3) starik-2005, Методика хорошая. Но оценка задачи не всегда быстрое дело и собрать "игроков за покерным столом" дело довольно хлопотное и последних надо как-то мотивировать.
Spacer; LordChesterfield; klinval; +3 Ответить
13. starik-2005 3031 12.08.16 13:52 Сейчас в теме
(7) все зависит от процессной зрелости компании, которая занимается внедрением. Если это профессионал-одиночка, то, конечно, риски для заказчика высокие, но ценник кажется небольшим. Если это компании со зрелыми процессами, то риск минимальный, т.к. озвученный бюджет и временные сроки проекта будут соблюдены.

Отсюда как бы легко и просто вытекает то, что с серьезными заказчиками крайне редко будет работать какой-то такой одинокий волк, удел которого мелкие компании с маленькими бюджетами и бесконечной рутиной. И этот разработчик - это их риск, про который они вообще ничего не знают из-за незрелости риск-менеджмента и невысокой капитализации компании в целом, не позволяющей им привлекать специалистов, компетентных в данной области, ибо оная не кажется им важной. Крупные компании работают двумя путями: сокращают риски или обогащают ответственных сотрудников за счет купленных тендеров. Но мелкая компания тендер все-равно не купит, так что риски в любом случае учитываются.
zhyhallo; SamBadi; +2 Ответить
15. SamBadi 209 12.08.16 15:00 Сейчас в теме
(13) starik-2005, и в очень больших компаниях на очень больших проектах ответственность за оценку задач ложится на конечного человека. В статье речь идет именно про оценку программиста, а не технического руководителя проекта, архитектора, ответственного за блок или иного ключевого лица на проекте.
Даже оцененные заказчиком, расписанные ответственным задачи или дают программисту на оценку, или программисту надо понять возьмется ли он делать за указанные часы или в указанные сроки (в конечном итоге те же часы для руководства). В такой ситуации, программист практически никогда не несёт рисков за неверную постановку, скорее всего ему закроют часы сверх оговоренного если он приведет хоть одну причину увеличения трудозатрат. Но, даже в такой ситуации возникают конфликты когда, например, руководитель разработки пытается надавить на разработчика и заставить его сделать что-то бесплатно (сверхурочно) или, что чаще в моей практике, разработчик безропотно соглашается, а потом постоянно, без аргументов, сдвигает сроки, что портит репутацию программиста.
Программисту, в конечном итоге, всегда надо ясно представлять себе что и как делать, уметь объяснить, что мешает ясной постановке, понимать, что прояснение постановки это тоже работа.
16. starik-2005 3031 12.08.16 15:43 Сейчас в теме
(15) ну тут все упирается в опыт программиста по оценке. Если он подобную задачу делал - проблем нет. Если не делал - тогда как он поймет, сколько времени на это понадобится? Но я говорю о другой технологии работы, когда все загоняются не в проект, а в спринт-команды по пять-семь человек. Это один из вариантов гибкой методологии разработки. Суть в том, что группа разработчиков со скрам-мастером выбирают из пула задач те, которые они будут реализовывать в этот спринт. Алгоритм прост: пока в пуле задач есть задачи, выбирают оттуда максимально приоритетную задачу, проводят покер планирования, определяются окончательно со временем, засовывают задачу в спринт и определяют ответственного. Ну и так далее пока есть задачи или есть время в спринте (количество разработчиков * рабочее время спринта). Забивая спринт подзавязку, они приступают к работе над ним. Скрэммастер следит за сроками, производит замены задач из пула на низкоприоритетные задачи спринта в случае острой необходимости, согласовывая время. В итоге скорость разработки, прозрачность и управляемость процесса выходят на совершенно иной уровень, который в проектном производстве невозможно достичь.
sulfur17; SamBadi; +2 Ответить
20. SamBadi 209 12.08.16 16:55 Сейчас в теме
(16) starik-2005, звучит довольно заманчиво. Надо попробовать на практике.
9. zhyhallo 99 12.08.16 10:54 Сейчас в теме
(3) starik-2005, поставил +1. Хотел только добавить, что бывают задачи, которые реально оценить сложно. Да, и нету на это времени. Инциденты не рассматриваются в рамках спринта. С клиентом лучше договорится по факту затраченного времени на их выполнение.
Mortiferus; +1 Ответить
10. TODD22 18 12.08.16 11:31 Сейчас в теме
(3) starik-2005,
а потом тех, кто дал экстремальные оценки, спрашивают, почему.

Ага и тот кто дал экстремально минимальные оценки(времени, трудозатрат ит д) сам выполняет задачу.
DarkAn; dj_serega; sigmov; AlmazBur01; h00k; SamBadi; +6 Ответить
14. starik-2005 3031 12.08.16 13:53 Сейчас в теме
(10) TODD22, это, видимо, в Вашем колхозе так. Колхозников не жалко.
6. Acasta 1 12.08.16 09:11 Сейчас в теме
Оценка у меня всегда зависит от клиента и от цены за час. Лояльный - моя примерная оценка + половина от нее. Низкая цена за час - моя оценка плюс еще столько же. Бывает и за ту же оценку, если клиент новый или жадный. В итоге, даже, если недооценка, выходит нормально. С проектами тяжелее. Так как его надо продать и ты новичок на рынке - оценка низкая. У тебя лобби - оценка завышенная. Бывает объем по проекту растет, тут зависит от того, как сможешь обосновать повышение стоимости проекта. На проектах фактическая оценка, по опыту работы, нужна для расчета себестоимости проекта.
Spacer; sulfur17; +2 Ответить
8. klinval 337 12.08.16 10:53 Сейчас в теме
Как по мне: адекватная оценка приходит с опытом. Когда я ещё работал во франче начальник (не программист) мои программистские задачи оценивал всегда более адекватно нежели я. Просто у него в этом было больше опыта, он выслушивал задачу + мою оценку и выдавал правильную оценку.
Причём заметил особенность: моя оценка обычно в 1,5 - 2 раза меньше действительно затраченного времени. Когда я свою оценку сразу озвучивал умножая на 1,5 начальник соглашался (хотя не знал что я умножил) и я обычно укладывался в эти сроки.

Был даже случай когда простенькую переделку отчета на 2 часа я заложил 4 часа (никогда так раньше не делал на столь малой работе, но именно тут что-то "щёлкнуло"). И не прогадал: работу то я сделал за 2 часа, но сдавал я её ещё 2 часа: были нюансы/вопросы заказчика, фактически не совсем по теме задачи, переделкой отчета во вторые 2 часа не занимался.

А так нашу Программистскую работу трудно оценить (даже постфактум). Разве ни у кого не бывало, когда за первую половину дня написал сотни строк кода, а во второй половине дня "встрял" и по факту за вторые 4 часа написал пару строк? Порой и правда бывает, что "90 процентов работы делается за 10 процентов времени"...
DarkAn; Spacer; Rain88; mytg; Olenevod; AlenaR; Nelli_A86; EvgeniusRusius; arakelyan; dj_serega; teyana; vasiliy_b; Award; GATTUSO; sigmov; AlmazBur01; ZOMI; sulfur17; roofless; kraynev-navi; SamBadi; +21 Ответить
11. tailer2 12.08.16 12:59 Сейчас в теме
Фиксируйте все ответы, даже неадекватные ответы.


особенно неадекватные
12. tailer2 12.08.16 13:06 Сейчас в теме
давным-давно, во времена позднего фриланса, я предлагал обратиться к франчайзям с обещанием сделать эту задачу за выставленную франчайзями цену

указания заказчика на НДС и т.п.разницы игнорировал: нал, значит нал, хотите НДС - идите к франям
17. necropunk 9 12.08.16 16:00 Сейчас в теме
Мне кажется или я уже где-то читал эту статью, то ли на сайте кодерлайна, то ли на сайте итрп...
h00k; SamBadi; +2 Ответить
18. h00k 50 12.08.16 16:45 Сейчас в теме
(17) necropunk,
Мне кажется или я уже где-то читал эту статью

Не кажется ;)

на сайте кодерлайна


Сам вчера столкнулся с сильным чувством дежа-вю и хотел возмутиться, но потом нашел статью которую я видел раньше и сравнив авторов успокоился :D
19. SamBadi 209 12.08.16 16:53 Сейчас в теме
(17) necropunk, + за внимательность. На сайте Кодерлайна (работаю там) немного модифицированную (разделенную по блокам) коллегами редакторами версию статьи выложили.
21. Yashazz 4707 12.08.16 17:46 Сейчас в теме
Чего никогда не понимал, как подобные самоочевидные вещи, изложенные в статье, могут ещё вызывать интерес. Тем более выраженный в таком рейтинге публикации... Это же всё давно дважды-два-четыре, что нового-то сказано?

А насчёт рисков - знаете, тут недавно представитель одного довольно крупного заказчика заявил: "наши риски - это то, что мы согласимся на более высокую цену, которую предлагаете вы, чем на ту, что другие участники конкурса". Т.е. человек вообще не понимает, что такое риски проекта, а именно он и выбирает автоматизатора. Ну и о чём мы все тут говорим?..
AlenaR; tailer2; h00k; SamBadi; +4 Ответить
22. SamBadi 209 12.08.16 18:46 Сейчас в теме
(21) Yashazz, Есть книга Роберта Кийосаки "Бедный папа, богатый папа". Советую почитать. Там на протяжении большого количества страниц расписывается одна мысль: "чтобы денег было больше: надо меньше тратить и больше зарабатывать". Были еще мысли про инвестиции, но они, по-моему, не очень пригодны для нашей страны. В своё время эта банальная книга с самоочевидными вещами мне помогла гораздо больше чем сложные книги. Надеюсь, что кому-то поможет и эта очевидная статья.

Насчет заказчиков, с ними работа конечно очень сложна. Даже бывшие разработчики из франчайзи, становясь заказчиком, начинают продавливать сроки и цену, торгуясь за свои бюджеты. Люди же далекие от разработки ПО, похоже, не всегда понимают, что закупка сена и заказ на разработку ПО принципиально разные вещи. Тут уж имеем, что имеем.
26. Petr54-ru 90 13.08.16 12:51 Сейчас в теме
(21) Yashazz,

А насчёт рисков - знаете, тут недавно представитель одного довольно крупного заказчика заявил: "наши риски - это то, что мы согласимся на более высокую цену, которую предлагаете вы, чем на ту, что другие участники конкурса". Т.е. человек вообще не понимает, что такое риски проекта, а именно он и выбирает автоматизатора. Ну и о чём мы все тут говорим?..


Заказчик этот, как надо все прорубает. Он для себя оценил риски проекта, в виде некоей суммы, которая будет как-то соответствовать его потерям, если проект не будет реализован. Каким образом он может снизить свои риски? Выбрать самого компетентного исполнителя. Он нашел самого компетентного исполнителя в лице вашей конторы, собственно разница между вашей ценой и самой минимальной и будет его платой за риск. Если эта "дельта" меньше той цифры, в которую он оценил риски проекта, то он молодец и все правильно сделал.

Есть еще один забавный момент - Кто несет большие риски, заказчик или исполнитель? В очень многих случаях, исполнитель рискует куда больше. Например, в случае провала проекта исполнитель может вообще ничего не получить, или например вернуть авансы и выплатить неустойку. И вместе с выплаченной неустойкой и возвартом авансов вылететь в трубу. Не раз приходилось сталкиваться с такими прецедентами.
23. bulpi 215 12.08.16 23:31 Сейчас в теме
Да ерунда все это. Я говорю заказчику : я точно сделаю работу. Цену скажу, когда сделаю. По соотношению цена - качество мне никто в обозримом пространстве не конкурент. Не хочешь - свободен, за мной очередь стоит. Сделал, не устраивает цена - свободен навсегда. Но такой поход годится только в том случае, если есть железобетонная репутация и уверенность в себе. А это приходит с годами и десятками внедренных проектов за низкие цены.
Spacer; vasiliy_b; Mortiferus; unpete; +4 Ответить
51. WasiliyMay 8 11.03.17 12:35 Сейчас в теме
(23)Вы, видимо, забыли уточнить, что выполняете очень мелкие работы. Ни один человек с опытом не станет работать на таких условиях. Представьте небольшой проект, хотя бы месяц, по окончании которого вам говорят, что нас не устраивает цена. Вы развернетесь и уйдете? Оценивая работы, вы в первую очередь защищаете себя от будущих проблем
24. МимохожийОднако 140 13.08.16 08:55 Сейчас в теме
Можно долго согласовывать и торговаться с Заказчиком. Но если ты не профи, а профан в работе, то это всё не поможет.
25. starik-2005 3031 13.08.16 09:49 Сейчас в теме
Какие, смотрю, крутые спецы собрались! Идите к нам работать, а то работы - море просто!
41. vis_tmp 32 24.08.16 09:53 Сейчас в теме
(25) starik-2005, "к нам работать" - это куда?
42. starik-2005 3031 24.08.16 10:21 Сейчас в теме
(41) vis_tmp, считай, что это первый вопрос на собеседовании ))
43. vis_tmp 32 24.08.16 14:54 Сейчас в теме
(42) starik-2005, А я фрилансер )
44. starik-2005 3031 24.08.16 17:31 Сейчас в теме
(43) vis_tmp, ну тогда это не для Вас.
27. maxx 991 13.08.16 18:31 Сейчас в теме
Часто сталкиваюсь с такой ситуацией по оценке задач в проектах.
Заказчика интересует сумма проекта. Проект - это список задач. Заказчику нужно сказать сколько это будет стоить. На этом этапе со стороны Заказчика по сути нет людей, которые могли детально расписать нюансы всех задач. Эти люди в принципе есть, но т.к. проекта ещё нет, нет приказа директора о назначение ответв.лиц за проект, то все очень пассивны и инертны. Но проект упускать не хочется, т.к. есть перспектива получение или опыта или развитие направления. В итоге делаешь грубую оценку. Получаем сумму проекта и очень часто Заказчик теперь проводит эту сумму через процедуру конкурса. Потом когда конкурс выигран и можно начинать работать, все лица со стороны Заказчика "просыпаются" и начинает вылазить куча нюансов.

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

maksa2005; morin; Spacer; Sure; lina_00; fomix; manu; sigmov; sulfur17; +9 Ответить
28. Petr54-ru 90 13.08.16 19:31 Сейчас в теме
(27) maxx,
В итоге получаем вилку: с одной стороны, Заказчику нужна для оценки сумма проекта чтобы понять вообще о каком порядке сумм идёт речь, но на этапе согласовании сметы ещё трудно всё оценить; с другой стороны, когда Сумма проекта уже зафиксирована, границы задач начинают расширяться и мы можем попасть на кучу бесплатной работы.


А если заказчик воспринял идею варки супа из топора как руководство к действию, то исполнителя ждет масса интересного.

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

Если заказчик вменяем и способен к диалогу, то есть два способа. Тут на первое место выходит работа с ожиданиями клиента. Об эти способы нужно заранее с закзчиком обговорить "на этом берегу", например так - Мы знаем, что в процессе выполнения проектов у ваших людей появится масса "хотелок", которых сейчас в проекте нет. С этими "хотелками" торопиться не надо, поскольку наш опыт говорит о том, что 80% этих "хотелок" не правильные, а когда люди 3-6 месяцев поработают в программе у них появятся совсем другие хотелки - и это будут уже "правильные хотелки". Есть два способа - первый способ мы аккуратно собираем все "хотелки", сдаем вам проект в том виде, как согласованно сейчас, а после сдачи согласуем следующий проект, в котором оперативно все эти "хотелки" реализуем. Либо второй вариант - если ли решаете, что в проект надо нечто в функционал добавить, одновременно с этим вам нужно будет решить что придется из функционала проекта выкинуть. Для наглядности можно привести пример ремонта автомобиля на СТО - пригнал машину тормозные колодки заменить, заодно за эту цену двигатель откапитальте
Sure; AlenaR; vasvl123; fomix; AlmazBur01; sulfur17; +6 Ответить
29. maxx 991 13.08.16 20:21 Сейчас в теме
(28)
первый способ мы аккуратно собираем все "хотелки", сдаем вам проект в том виде, как согласованно сейчас, а после сдачи согласуем следующий проект, в котором оперативно все эти "хотелки" реализуем

Эх, если бы было так всё просто. Очень часто у людей, которые и сбрасывают "хотелки" и отвечают на вопрос: "Исполнители говорят, что проект закончили. Это так?" и вот тут они начинают: "Ну как бы, что-то сделали , всё по ТЗ, но ничего не работает как надо, т.к. много всего не хватает".
sulfur17; +1 Ответить
30. Petr54-ru 90 13.08.16 20:57 Сейчас в теме
(29) maxx,

Либо неправильная технология работы с заказчиком либо, цель заказчика - получить от вас "за рубль паровоз".

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

Вам надо продумать технологию работы с заказчиком по договору, которая бы исключала такие варианты. Это реально.
34. maxx 991 14.08.16 11:29 Сейчас в теме
(30)
Вы выполнили работы в объеме ТЗ. По факту, с вас трясут объем неоплаченной работы по реализации того, чего в ТЗ не было

Я с вами согласен во многом. Но все время сталкиваешься с ситуацией недосказанности на начальном этапе.
Пример:
Присылают по электронке печатную форму акта услуг. Посмотрев на нёё, можно сказать что это стандартный акт, который присоветует в бухгалтерии, только в наименование услуге выведен Месяц, за который услуги оказаны, исходя из даты документа. Уточнив всё это, технический специалист понимает, что работы немного изменить описание услуги при подстановки номенклатуры в тч. Оценка технич.специалиста - 1 ч. В договор в тз включена скан-форма печатной документа.

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

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

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



sulfur17; +1 Ответить
31. TreeDogNight 22 13.08.16 21:24 Сейчас в теме
(29) maxx, В таких случаях небходимо использовать Тест-кейсы на каждую функцию, описанную в ТЗ, требуя подписи от Ответственных лиц Фирмы-Заказчика. Тогда в случае фраз "но ничего не работает как надо" можно смело указывать на подписанные Тест-кейсы.
32. TreeDogNight 22 13.08.16 21:27 Сейчас в теме
Хотелось бы узнать, как Программисту наиболее правильно оценивать задачи "Инновационного типа", с которыми он ещё не встречался, например интеграция с какой-нибудь редкой системой?
user_2010; sulfur17; +2 Ответить
33. Petr54-ru 90 14.08.16 04:06 Сейчас в теме
(32) TreeDogNight,

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

Тут надо две вещи понимать. Во-первых, в любом случае много шансов облажаться с оценкой трудозатрат, А во-вторых, есть у инновационных задач есть особая ценность, например выход за деньги заказчика в новую область компетенции или опять же за деньги заказчика случается "пилотник" и выходишь на новый рынок с новыми возможностями. Я например люблю такие инновационные задачи.
Swamt; AlenaR; sulfur17; TreeDogNight; +4 Ответить
35. TODD22 18 14.08.16 13:08 Сейчас в теме
(33) Petr54-ru,
Я в таких случаях беру паузу и объясняю что ничего похожего не делал и что мне нужное некое конкретное время для оценки работы.

Это при условии что заказчик готов платить за процесс. Заказчики то же умные пошли... И хотят покупать готовые решения, а не процесс.
37. CheBurator 3119 14.08.16 18:23 Сейчас в теме
(35) а всеразработчики тоже умные
Все шире и шире продают процесс
38. Petr54-ru 90 15.08.16 05:45 Сейчас в теме
(35) TODD22,
Это при условии что заказчик готов платить за процесс. Заказчики то же умные пошли... И хотят покупать готовые решения, а не процесс.


Если есть готовое решение - надо продавать готовое решение. Нормальный вариант, если разработчик готового решения (типа вендор), даст возможность внедренцу (типа системному интегратору) заработать на продаже лицензий 45-55% и впоследствии двигать дальше это готовое решение. Тогда у внедренца состоится "пилотник" и он дальше сможет за деньги заказчика выйти на новый рынок. Так реально бывает. Если разработчик не хочет придружить системного интегратора, который бы за долю справедливую продвигал бы у себя в регионе его решение - то тогда это просто не ваш клиент.

Продавать процесс хорошо, когда специфика клиента настолько кривая, что нет нормального готового решения или готовое решение станет "костылем" для всего их остального ПО и заказчик стоит перед выбором - или "допилить" их конфигурацию, или разводить у себя "зоопарк" из конфигураций. Так тоже бывает.
36. tango 506 14.08.16 13:56 Сейчас в теме
(С) Альберт Великий, Libellus de Alchimia

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

Если тебе поручено некое златоискательское дело, они не перестанут терзать тебя время от времени расспросами: "Ну, мастер! Как идут твои дела? Когда, наконец, мы получим приличный результат?" И, не дождавшись окончания работы, они станут всячески глумиться над тобой.

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

Если же, напротив, ты будешь иметь успех, они постараются задержать тебя в плену, где ты будешь работать им на пользу, не имея возможности уйти. Считай, что лишь из-за собственных слов и твоих собственных рассуждений ты попался в ловушку.
Поручик; Sure; Andrsan; AlmazBur01; intekoserg; user_2010; TreeDogNight; +7 Ответить
40. starik-2005 3031 17.08.16 22:50 Сейчас в теме
(36) tango,
Не выходи из комнаты, не совершай ошибку.
Зачем тебе Солнце, если ты куришь Шипку?
За дверью бессмысленно все, особенно -- возглас счастья.
Только в уборную -- и сразу же возвращайся.

О, не выходи из комнаты, не вызывай мотора.
Потому что пространство сделано из коридора
и кончается счетчиком. А если войдет живая
милка, пасть разевая, выгони не раздевая.

Не выходи из комнаты; считай, что тебя продуло.
Что интересней на свете стены и стула?
Зачем выходить оттуда, куда вернешься вечером
таким же, каким ты был, тем более -- изувеченным?

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

Не выходи из комнаты. О, пускай только комната
догадывается, как ты выглядишь. И вообще инкогнито
эрго сум, как заметила форме в сердцах субстанция.
Не выходи из комнаты! На улице, чай, не Франция.

Не будь дураком! Будь тем, чем другие не были.
Не выходи из комнаты! То есть дай волю мебели,
слейся лицом с обоями. Запрись и забаррикадируйся
шкафом от хроноса, космоса, эроса, расы, вируса.
Показать
39. al_zzz 309 17.08.16 09:01 Сейчас в теме
Моя адекватная оценка тз - это компромисс между моей ленью и жадностью заказчика.
45. Xolli 03.09.16 15:38 Сейчас в теме
какой будет второй вопрос?
46. docerman 70 21.09.16 11:01 Сейчас в теме
Я пользовался простым способом. Если брать пример из статьи максимум 100 часов, минимум 6 часов, то формула оценки такая - среднее значение (100 + 6)/2 = 53. У автора статьи получилось 49, почти как у меня. Только аргументация у меня как Шарикова - взять все и поделить - но такая оценка у меня всегда получалась наиболее близкой к истине.
47. biimmap 1795 22.09.16 11:21 Сейчас в теме
Автору спасибо за полезную статью. но я работаю по факту или на окладе. Ну их всех со своими оценками... А сейчас вышли ЗУП 3.0 и ЕРП как можно прогнозировать когда ты ни разу не копался в коде этих конфигураций))) Статья хорошая, но как спрогнозировать то, чего ты вообще не знаешь. вот это было бы интересно понять.

Приведу пример: я работал в 1С. мой профиль ЗУП. мне дали задачу по казначейству, которая для человека знающего казначейство очень простая. Но я первый раз в глаза увидел ЕРП. А с казначеем ни с одним не знаком лично!

В итоге мне нужно понять 5 моментов:
1. Предметную область (как оценить время на её изучение если ты не знаешь даже рамки этой области)
2. Архитектуру решения ЕРП (вопрос тот же)
3. Функциональность каждого из документов/справочников/регистров (их огромное количество)
4. Сценарии работы пользователей (их в принципе знают только разработчики каждой отдельной подсистемы! и они нигде не описаны)
5. Структура кода (какие способы реализации были применены при программировании интерфейсов, движений, проверок)

Вот я пока не встретил человека который мне смог бы ответить как не зная эти 5 пунктов оценить задачу и как оценить собственно эти 5 пунктов.

Если я это когда-нибудь узнаю, я стану гуру планирования))) А пока всех посылаю и работаю на окладе)))
54. Melkiy 09.09.20 12:00 Сейчас в теме
(47) Полностью согласен. Как можно планировать то, чего никогда не делал? Все эти оценки чисто субъективны и основаны только на опыте. Я не читал этих "умных" книжек, про которые пишут выше, но уверен, что там написано не имеет никакого рельного смысла
48. agulaev 33 22.09.16 18:24 Сейчас в теме
Главное постановка, если пользователь не может объяснить чего хочет, то и дело не пойдет.
49. klinval 337 26.09.16 10:36 Сейчас в теме
(48) agulaev, если пользователь не может объяснить чего хочет, то обычно даётся оценка на поставку ТЗ. Т.е. за 10 (50, 100 или любая другая цифра) часов специалист внедренец вникнет в задачу, за пользователя составит требования и напишет ТЗ в котором будут уже изложены все аспекты задачи.
50. DmitriyPerevalov 09.03.17 21:13 Сейчас в теме
Автору спасибо!

От себя добавлю.

Оценки бывают предварительные или на основании конкретных требований.

Предварительная оценка выполняется при минимуме вводных и необходима, когда требуется сориентировать заказчика по объёму трудозатрат и стоимости. Результатом оценки будет "вилка" или три значения (вилка + средневзвешенное значение, которое будет ответом, если требуется назвать не вилку). Детальных требований на предварительной оценке, как правило, просто нет.

Для предварительных оценок есть разные методы: метод по аналогии, Pert и т.п. В любом случае для этих методов необходимо долго накапливать статистику, на основании которой будет выполняться "расчёт вилки", именуемый экспертной оценкой. Всё сводится к приобретению богатого опыта. Работает примерно так, если программист в основном пишет отчёт на СКД со сложными настройками за два дня +/- несколько часов, то оценка для такой же аналогичной задачи будет: два рабочих дня +/- несколько часов. Будет эта задача аналогична тому, что программист уже делал или нет, знает только программист, исходя из своего богатого опыта. Всё это относится и к PM-у, тимлиду и др., если он знает, как работает программист и на сколько у него богатый опыт.

Более точные оценки дают методы UCP, AFP, но они и более сложные и для них обязательно наличие детальных требований.И всё равно требуется накопленная статистика.

В статье автора для примера был описан метод предварительной оценки "По аналогии". Только для нижней оценки был взят случай совсем неопытного программиста. Опытные всё-таки дают нижнюю оценку не "как повезёт", а более точную и взвешенную, исходя из опыта.

Хорошая новость: если начать применять один из этих методов, то самая неправильная оценка будет всего одна - первая. Остальные оценки будут точнее и лучше.

Если программист не знаком с каким-то направлением, но кроме него задачу поручить некому (например, есть штатный программист и фирма не горит желанием привлекать разработчиков со стороны), то ни о каких предварительных оценках речь идти не может. Необходимо как можно точнее поставить задачу (собрать детальные требования - автор предоставил хорошие рекомендации в статье) и заложить время на изучение программистом предметной области. Если заказчик на это не согласен, то задача не выполняется или выполняется внешним (более опытным) подрядчиком - всё просто.
Важно! Программист не должен молчать о пределах своих возможностей ради сохранения своей репутации. Не надо бояться озвучить, что задача не по плечу, иначе репутация точно пострадает. Намного хуже и страшнее будет, когда начальство будет разбирать почему проект потерпел крах - вот, где реально можно навалить полные штаны кирпичей, особенно для неопытных "завальщиков проектов", т.е. программистов.
В этом контексте программисты делятся на две категории: те, кто адекватно оценивает свои силы и те, кто будет адекватно оценивать свои силы.

Если заказчик готов предоставить больше вводных, то конечно стоит идти по пути сбора полных требований, И уже на основании точных требований дать оценку по трудозатратам и стоимости (см. статью автора, там всё доступно написано).

То о чём автор решил не писать, всё равно нужно взять в поле своего внимания.

Уточнение оценок должно выполняться постоянно вплоть до сдачи продукта заказчику.
Согласованные требования - это хорошо, но как всегда "ровно было на бумаге, да забыли про овраги".
Если задача крупная, то уточнение оценок происходит после каждого из этапов:
- подробная разработка аппаратной архитектуры;
- подробная разработка программной архитектуры;
- непосредственная разработка;
- тестирование на стороне разработчиков.
По опыту на этих этапах всегда находятся непредвиденные проблемы, которые порождают новые задачи, а они в свою очередь имеют длительность и стоимость.
Опять же по опыту, заказчику не всегда это нужно знать (смотря какой заказчик), а в проекте лучше просто заложить 10% дополнительного времени, чтобы втиснуть "непредвиденные задачи" в уже согласованные временные рамки. Эта рекомендация относится к задачам и проектам высокой сложности и/или длительным по времени.


И всё это нужно для того, чтобы скорректировать свои оценки в будущем.

Для того, чтобы оценки были более точными, не было страха выполнить предварительную оценку и времени на оценку для каждых новых проектов и задач уходило меньше, всегда по окончании (после сдачи) проекта/задачи необходимо проводить ретроспективу: какой была оценка первоначально, какими сроки и стоимость оказались по факту; что повлияло на появление разницы; что нужно сделать, чтобы на будущее это учесть. А это напрямую влияет на то, о чём автор говорит в своей статье.

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

Вывод можно сделать следующий:
Оценка сроков и стоимости (в области разработки) - это циклический процесс на протяжении всей трудовой деятельности разработчика (тимлида, РМ-а, руководителя разработчиков). На каждом цикле фиксируется план и факт оценки конкретной задачи или проекта, объём работ; проводится анализ соответствия плана факту, выявляются все нюансы, повлиявшие на конечные срок, трудозатраты и стоимость; корректируются показатели, по которым проводится оценка, чтобы повысить её точность на следующем цикле.


И ещё чуть-чуть оффтопа.

К рекомендациям из статьи стоит добавить следующее:
- при сборе подробных требований и ограничений обязательно соберите и подробно задокументируйте сведения, какие "хотелки" в момент обсуждений было решено оставить за рамками проекта (т.е. заказчик хочет, но в силу сложности, длительности или высокой цены, от этого решили отказаться на этапе сбора и согласования требований).
Это не влияет напрямую на оценку сроков и стоимости, но очень сильно облегчает жизнь, когда через несколько месяцев работы в проекте заказчик, благополучно забыв о договорённостях, вспоминает о своих "хотелках" и требует их от вас. В такие моменты сильно повышается риск или разрыва отношений, срыва проекта или его удлинение с неприятными потерями в деньгах и психическом здоровье.
По факту - это минимизация одного из рисков, который может сделать вашу оценку "неадекватной" в глазах забывчивых заказчиков и даже РМ-ов и руководителей. Если такая ситуация всплывёт и вы аргументировано ответите на претензии, сомнений в вашей способности адекватно оценивать сроки не будет и параллельно заработаете репутацию опытного специалиста.

Что делать, если по "политическим мотивам" программиста хотят заставить понизить оценку сроков?
Надо прийти к компромиссу. Если время на уже известный объём задач надо сократить, то есть два варианта.
1. Вместе с заказчиком (через руководителя или PM-а) решить, что из общего объёма задач можно выбросить и не реализовывать, чтобы требуемый срок и трудозатраты были сопоставимы и адекватны. Ночных переработок из-за этого быть не должно. В этом случае проект лучше повести по SCRUM (если есть опыт в этом) - у нас есть два месяца и вот такой конечный результат нужен, что можно по максимуму выполнить за это время, чтобы удовлетворить заказчика. 2. Если же закзачик отказывается уменьшать объём задач, тогда сообщите, что требуется выполнить переоценку стоимости проекта/задачи. Закзачик должен понимать, что за ночные переработки придётся расплачиваться рублём. Или руководитель программиста должен раскошелиться на оплату сверхурочных программисту. Вместо оплаты сверхурочных может быть любая другая компенсация, например, добавлены дни к отпуску, оплаченный массажист, абонемент в бассейн и т.п. Программист обязан думать в первую очередь о себе и своём здоровье, своих личных интересах. После этого договариваться "по дружески" становится приятно, начинаешь понимать чего стоишь (вы же программируете не ради программирования?) и с какими заказчиками не стоит иметь дело.
Да, когда начнутся разговоры о сокращении сроков, в любом случае ставьте заказчика в известность, что все работы по проекту будут приостановлены, т.к. требуется время на переоценку проекта/задачи и в любом случае, хочет заказчик или нет намечается смещение срока в проекте. Добейтесь, чтобы "политические мотивы" и новые оговариваемые сроки с аргументацией от заказчика были зафиксированы в том виде, который по условиям договора (вы же работаете по договору?) можно предъявить в суде (конечно на всякий случай). Заказчик должен понимать и подтвердить, что причина остановки проекта и смещения срока - он сам. Или пусть забудет о своих "политических мотивах". Иногда без таких мер никуда не продвинешься.
А если программист будет молчать, то очень быстро подорвёт своё здоровье, так и не заработав нужной суммы на дорогостоящее по нынешним меркам лечение, и как плачевный итог - надпись "fatal error" уже на надгробной плите. Я не преувеличиваю! В 2017 году от кровоизлияния умер коллега - тот кто всегда может поработать "до упора", если попросить и просить стали часто. С работы ушёл вовремя, придя домой, решил что мало выполнил за день, подключился удалённо и приступил к выполнению очередных задач. Умер за компом в кресле с открытым рабочим местом по "удалёнке".

Берегите себя! Оценивайте задачи и свои силы адекватно!
smirnovserg.s@gmail.com; Olenevod; Sure; +3 Ответить
52. user643267_eturin 30.03.17 14:27 Сейчас в теме
Считаю, кроме всего прочего не стоит забывать про старый добрый SMART. Ведь оценка это как раз буква "M". Если вы четко определились с остальными: целью (S), инструментами (A), оптимальным способом достижения ® и сроками (T) то дать оценку, это как в поле чудес слово отгадать с одной закрытой буквой.
53. Melkiy 09.09.20 11:52 Сейчас в теме
Действительно очень интересная статья. Но вот я, как начинающий, как могу определить данные сроки? Даже банально вот по созданию нового справочника (хотя понимаю что это не долго), но все равно, как определить, что это будет 2 часа, а не 8 или не 20? Я так полагаю только по опыту можно. Или ошибаюсь. Спасибо если ответите
Оставьте свое сообщение