Наиболее типичные ошибки при оценке работ в проектах 1С

13.06.20

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

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

1.    Ошибки программистов и удаленных разработчиков

 

1.1.       Недооценка времени на тестирование и исправление.

Подумайте, вы правда умеете программировать сразу без ошибок? Если нет, смело закладывайте время на тестирование. Сколько? Зависит от задачи – вы профессионал, вам виднее.

 

1.2.       Недооценка времени на уточнение формулировок задачи проекта.

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

 

1.3.       Недооценка времени на подготовку к работе.

Где будет происходить разработка? У вас на компьютере? На сервере заказчика? На сервере компании? А база уже развернута? А есть доступ? А получен ли cf, если «конфигурация заказчика немного изменена»? Эти вопросы надо задать и понять, потребуется ли время на подготовку. Если потребуется, и подготавливать будете Вы, включайте время в оценку.

 

1.4.       Недооценка сдачи-приемки.

Подумайте, кому и каким образом вы будете сдавать работу? Что для этого потребуется? Сколько это займет времени? Вы сдаете работу не одному человеку, а нескольким (такое бывает)?

 

1.5.       Недооценка окружения.

Заказчик использует хранилище конфигурации, разработка ведется в расширении, «вот вам простой и понятный регламент работы и документирования кода всего на 25 страницах»? Если вы с этим работали, то понимаете: на сколько умножить, если работа с хранилищем; на сколько, если с расширением; сколько процентов на страницу регламента закладывать. Если не работали – смело умножайте на 1.5 за каждый вид неопределенности. Скорее всего, все равно не угадаете, но это будет не так обидно.

 

1.6.       Не указали границы.

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

 

Тут 100% действующего рецепта нет – при постановке задачи не сказать могут что угодно. Если условия неизвестны, пишите свои предположения и их считайте «границей». Если вы имели ввиду, что вы только кодируете, только у себя, а в качестве сдачи-приемки отправляете cf по почте – напишите. Заказчик либо согласится, либо задумается и скажет: «Нет, я хочу, чтобы вы мне тестовый стенд развернули и показали, как это работает». Тогда вы уже вступаете в конструктивный диалог: «А тогда это будет стоить еще…». В любом случае, вы не будете работать бесплатно: если выяснится, что заказчик не готов за что-то платить, вы сами примете решение, готовы вы что-то сделать за бесплатно, или пусть поищет кого другого.

 

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

 

2.    Ошибки аналитиков – консультантов

 

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

 

2.1.       Правильно расписана последовательность работ.

Вы же понимаете, как будете решать поставленную задачу? В какой последовательности? Что будет результатом? Если понимаете, то напишите эту последовательность. Лучше всего в MSProject. Так вам станет понятно, когда вы на самом деле сделаете задачу.

 

2.2.       Не заложен резерв под исправление ошибок.

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

 

2.3.       Не заложен резерв под сдачу-приемку выполненных работ.

Как вы будете сдавать работу? Кому? Сколько это на самом деле займет времени? Надо ли будет куда-то ехать? Надо ли там кого-то ждать? Сможете ли вы сделать что-то еще, если поедете сдавать задачу к заказчику на Рябиновую улицу к 15? Если нет, то почему бы не включить часы вынужденного простоя в часы работы на заказчика, из-за которого этот простой вызван?

 

2.4.       Не учитываете транзакционные издержки.

Что это такое? Очень просто. Например, у вас мини-проект и вы договорились о серии интервью для уточнения задачи. И вот первое интервью у вас в 10:00, а второе в 15:00. Чем вы будете заниматься между ними?

 

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

 

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

 

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

 

2.5.       Не фиксируете результат, либо фиксируете нечетко.

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

 

3.    Ошибки при оценке последовательности проведения работ

 

Тут пойдет речь об оценке мини-проектов, где будет работать не только аналитик, но и разработчик (или два). В качестве тимлида в таких конструкциях обычно выступает аналитик, который и общается с заказчиком, ставит ТЗ, принимает работы у разработчиков и сдает результат Заказчику.

 

3.1.       Неправильно указана последовательность проведения работ.

Подумайте, как команда будет делать проект. Постарайтесь хотя бы не планировать так, чтобы кто-то делал одновременно две задачи. В реальности все равно так случится и тогда количество одновременных задач умножится на два. Если у вас запланированы две задачи одновременно, то будьте уверены – в какой-то момент их станет 4.

 

Помните, что разработчики ошибаются с оценкой (см раздел 1).

Помните, что нельзя писать инструкцию по неразработанному функционалу (например).

 

3.2.       Не учтены транзакционные издержки.

Как будет происходить передача задачи от вас программисту? А от программиста к вам? Что он будет делать, пока вы проверяете результат?

 

3.3.       Перегрузка ресурсов.

У вас проект на 9 человеко-месяцев, а надо сделать за один. Казалось бы, берем 9 программистов, и они все сделают за месяц. Но нет! Если один аналитик и девять программистов, то задача будет делаться скорее всего около года. Да-да, та самая, на 9 человеко-месяцев.

 

Не ваш случай? Так если у вас шесть программистов на 50% загрузки, то это хуже, чем 3 на 100%.

 

Почему? Потому что как бы не была декомпозирована задача, как бы вы не написали ТЗ, вам будут задавать вопросы при разработке (те самые, из п.1.2) Одному человеку вы объясните один раз. Шести – шесть. И вопросов будет в 6 раз больше.

 

3.4.       Ошибки окружения.

Если у вас работает несколько разработчиков, надо понимать, как вы будете объединять плоды их трудов. Кто и как это будет делать. Каким функционалом. Если будете объединять разные доработки в одной конфигурации, то не забудьте, что делая одно можно сломать другое. И лучше будет, если вы сами это обнаружите, чем «прилетит» от заказчика. А значит, надо заложить дополнительное время на все указанное выше.

 

Список конечно не исчерпывающий, но основное я указал. Теперь абзац для заказчиков.

Итак, уважаемые заказчики, если вы – получатель оценки, то надо все эти вопросы (из пунктов 1-2) задавать вашему исполнителю. Иначе может получиться, что ваш исполнитель получит существенно меньше, чем потратит времени. А вам-то что? Очень просто: он пару раз с вами поработает, а потом решит, что ему так не надо. И либо скажет, что больше не хочет так работать, либо просто исчезнет (хорошо если без предоплаты). Потому если вы нацелены на долгое сотрудничество – задавайте эти вопросы. Цените специалистов, проводящих работы в программе 1С, их и так мало!

#1С #программист #ошибки

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2779    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

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

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14310    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5856    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

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

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

10.02.2023    4706    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2750    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4189    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    10682    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13096    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Ruslan2011 13.06.20 10:29 Сейчас в теме
начинающему в самый раз , что-бы не думал, что все так просто :)
2. acanta 13.06.20 10:56 Сейчас в теме
Да ладно "мало специалистов". В коробке пачка книжек, заказчик любому своему стажеру после техникума/колледжа даст прочитать и готов программист 1с. Разве не так?
3. user1400964 13.06.20 21:44 Сейчас в теме
(2) Это был сарказм или просто делитесь успешным опытом подготовки программистов?
4. salus 28 14.06.20 10:04 Сейчас в теме
А вы уверены, что после такой оценки заказчик не найден другого исполнителя. потому что дорого?
5. user1400964 14.06.20 12:10 Сейчас в теме
(4)

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

так что совет "избыточно" оценивать стоимость задачи актуален для всех исполнителей кроме начинающих, т.е. для 99%
7. salus 28 15.06.20 06:23 Сейчас в теме
(5) Круто, конечно)) Реалии несколько иные. Особенно сейчас, когда заказчик выставляет жесткие требование по часам (я не возьму, другой возьмет. даже если и потратит в два раза больше). Но рынок нынче такой(( Сильнейший демпинг. ((
8. salus 28 15.06.20 06:25 Сейчас в теме
(7) При этом будет речь о том, чтобы придерживаться методики разработки.
9. user1400964 15.06.20 07:40 Сейчас в теме
(7)
Время такое, это да, и демпинг есть... Но если имеется неплохой пул заказчиков и есть из кого выбирать, то проблема решаема

конечно приходится больше крутиться и тратить время на коммуникации и поиск новых заказчиков, но что же поделать - "время такое" )
6. user1400964 14.06.20 17:01 Сейчас в теме
(4)

ПС: Да и статья вроде больше для заказчиков , а не для исполнителей....
Оставьте свое сообщение