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

0. Константин Вальков (SamBadi) 163 11.08.16 16:10 Сейчас в теме
Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

Перейти к публикации

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

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

В умных книжках подробно описаны масса различных методологий разработки, тысячи их, практически все методики предлагают рабочие методики оценки трудоемкости, бери подходящие по задачам и команде методики, пользуйся, какие проблемы?
Sure; AlenaR; nata0612@mail.ru; mike_grig; bulpi; Paradise.87; EliasShy; kuntashov; Светлый ум; +9 Ответить 1
2. Константин Вальков (SamBadi) 163 11.08.16 22:49 Сейчас в теме
(1) Petr54-ru, отчасти согласен, что от объема задачи напрямую зависит методика оценки.
Но какая-та градация у Вас выборочная, если придраться к вашей формулировке, то проект на неделю и на 5 лет находятся в одном "мире задач", а это не так.
Отвечаю на ваш вопрос: проблема в том, что тысяча книг написано, а коллеги разработчики, все равно избегают браться за задачу когда их просишь предварительно оценить, потому что, испытывают дискомфорт из-за возможности ошибиться. Пусть это будет тысяча первая статья, но если кому-то она поможет не отказаться от задачи и сделать её не себе в убыток, то цель достигнута.
Olenevod; Nelli_A86; Rustig; +3 Ответить 1
3. Sergey Andreev (starik-2005) 1135 11.08.16 23:04 Сейчас в теме
В методологии SCRUM для оценки задач для спринта используется технология покера планирования, когда независимо друг от друга разработчики оценивают задачу, а потом тех, кто дал экстремальные оценки, спрашивают, почему. В итоге таким образом рождается вполне реальная оценка, которая, исходя из практики применения данного подхода, оказывается куда точнее, чем обычная оценка.
dj_serega; Kserken; rpgshnik; dimadeev; necropunk; SamBadi; zhyhallo; Mi4man; miavolas; shalimski; +10 Ответить 4
4. Галахад Сэмюэл (dmt) 27 12.08.16 04:59 Сейчас в теме
Понравилось. Невнятные пожелания преобразуются в четкие требования.

(3) starik-2005, это когда есть ТЗ или внятные требования. А когда нет?
5. Петр Ивакин (Petr54-ru) 49 12.08.16 06:08 Сейчас в теме
(2) SamBadi,

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

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

Тут, относительно трудоемкости важно понимать две вещи:
1. Производительность двух программистов с одинаковым по времени опытом работы может отличаться в разы.
2. У программиста может быть в загашничке старая разработка которая с минимальными затратами может быть адаптирована под новую задачу (тот самый reuse).
AlenaR; lina_00; sevushka; Sup4ik; premier; sulfur17; teflon; SamBadi; Dem1urg; +9 Ответить
6. Алина Алинова (Acasta) 2 12.08.16 09:11 Сейчас в теме
Оценка у меня всегда зависит от клиента и от цены за час. Лояльный - моя примерная оценка + половина от нее. Низкая цена за час - моя оценка плюс еще столько же. Бывает и за ту же оценку, если клиент новый или жадный. В итоге, даже, если недооценка, выходит нормально. С проектами тяжелее. Так как его надо продать и ты новичок на рынке - оценка низкая. У тебя лобби - оценка завышенная. Бывает объем по проекту растет, тут зависит от того, как сможешь обосновать повышение стоимости проекта. На проектах фактическая оценка, по опыту работы, нужна для расчета себестоимости проекта.
sulfur17; +1 Ответить
7. Константин Вальков (SamBadi) 163 12.08.16 10:46 Сейчас в теме
(3) starik-2005, Методика хорошая. Но оценка задачи не всегда быстрое дело и собрать "игроков за покерным столом" дело довольно хлопотное и последних надо как-то мотивировать.
LordChesterfield; klinval; +2 Ответить 1
8. Валерий К (klinval) 208 12.08.16 10:53 Сейчас в теме
Как по мне: адекватная оценка приходит с опытом. Когда я ещё работал во франче начальник (не программист) мои программистские задачи оценивал всегда более адекватно нежели я. Просто у него в этом было больше опыта, он выслушивал задачу + мою оценку и выдавал правильную оценку.
Причём заметил особенность: моя оценка обычно в 1,5 - 2 раза меньше действительно затраченного времени. Когда я свою оценку сразу озвучивал умножая на 1,5 начальник соглашался (хотя не знал что я умножил) и я обычно укладывался в эти сроки.

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

А так нашу Программистскую работу трудно оценить (даже постфактум). Разве ни у кого не бывало, когда за первую половину дня написал сотни строк кода, а во второй половине дня "встрял" и по факту за вторые 4 часа написал пару строк? Порой и правда бывает, что "90 процентов работы делается за 10 процентов времени"...
Olenevod; AlenaR; Nelli_A86; Ganjubas; arakelyan; dj_serega; teyana; vasiliy_b; Award; GATTUSO; sigmov; AlmazBur01; ZOMI; sulfur17; roofless; kraynev-navi; SamBadi; +17 Ответить
9. Константин Жигалло (zhyhallo) 89 12.08.16 10:54 Сейчас в теме
(3) starik-2005, поставил +1. Хотел только добавить, что бывают задачи, которые реально оценить сложно. Да, и нету на это времени. Инциденты не рассматриваются в рамках спринта. С клиентом лучше договорится по факту затраченного времени на их выполнение.
Mortiferus; +1 Ответить
10. борян петров (TODD22) 16 12.08.16 11:31 Сейчас в теме
(3) starik-2005,
а потом тех, кто дал экстремальные оценки, спрашивают, почему.

Ага и тот кто дал экстремально минимальные оценки(времени, трудозатрат ит д) сам выполняет задачу.
dj_serega; sigmov; AlmazBur01; h00k; SamBadi; +5 Ответить 1
11. Andrey Erastov (tailer2) 12.08.16 12:59 Сейчас в теме
Фиксируйте все ответы, даже неадекватные ответы.


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

указания заказчика на НДС и т.п.разницы игнорировал: нал, значит нал, хотите НДС - идите к франям
13. Sergey Andreev (starik-2005) 1135 12.08.16 13:52 Сейчас в теме
(7) SamBadi, все зависит от процессной зрелости компании, которая занимается внедрением. Если это профессионал-одиночка, то, конечно, риски для заказчика высокие, но ценник кажется небольшим. Если это компании со зрелыми процессами, то риск минимальный, т.к. озвученный бюджет и временные сроки проекта будут соблюдены.

Отсюда как бы легко и просто вытекает то, что с серьезными заказчиками крайне редко будет работать какой-то такой одинокий волк, удел которого мелкие компании с маленькими бюджетами и бесконечной рутиной. И этот разработчик - это их риск, про который они вообще ничего не знают из-за незрелости риск-менеджмента и невысокой капитализации компании в целом, не позволяющей им привлекать специалистов, компетентных в данной области, ибо оная не кажется им важной. Крупные компании работают двумя путями: сокращают риски или обогащают ответственных сотрудников за счет купленных тендеров. Но мелкая компания тендер все-равно не купит, так что риски в любом случае учитываются.
zhyhallo; SamBadi; +2 Ответить 1
14. Sergey Andreev (starik-2005) 1135 12.08.16 13:53 Сейчас в теме
(10) TODD22, это, видимо, в Вашем колхозе так. Колхозников не жалко.
15. Константин Вальков (SamBadi) 163 12.08.16 15:00 Сейчас в теме
(13) starik-2005, и в очень больших компаниях на очень больших проектах ответственность за оценку задач ложится на конечного человека. В статье речь идет именно про оценку программиста, а не технического руководителя проекта, архитектора, ответственного за блок или иного ключевого лица на проекте.
Даже оцененные заказчиком, расписанные ответственным задачи или дают программисту на оценку, или программисту надо понять возьмется ли он делать за указанные часы или в указанные сроки (в конечном итоге те же часы для руководства). В такой ситуации, программист практически никогда не несёт рисков за неверную постановку, скорее всего ему закроют часы сверх оговоренного если он приведет хоть одну причину увеличения трудозатрат. Но, даже в такой ситуации возникают конфликты когда, например, руководитель разработки пытается надавить на разработчика и заставить его сделать что-то бесплатно (сверхурочно) или, что чаще в моей практике, разработчик безропотно соглашается, а потом постоянно, без аргументов, сдвигает сроки, что портит репутацию программиста.
Программисту, в конечном итоге, всегда надо ясно представлять себе что и как делать, уметь объяснить, что мешает ясной постановке, понимать, что прояснение постановки это тоже работа.
16. Sergey Andreev (starik-2005) 1135 12.08.16 15:43 Сейчас в теме
(15) SamBadi, ну тут все упирается в опыт программиста по оценке. Если он подобную задачу делал - проблем нет. Если не делал - тогда как он поймет, сколько времени на это понадобится? Но я говорю о другой технологии работы, когда все загоняются не в проект, а в спринт-команды по пять-семь человек. Это один из вариантов гибкой методологии разработки. Суть в том, что группа разработчиков со скрам-мастером выбирают из пула задач те, которые они будут реализовывать в этот спринт. Алгоритм прост: пока в пуле задач есть задачи, выбирают оттуда максимально приоритетную задачу, проводят покер планирования, определяются окончательно со временем, засовывают задачу в спринт и определяют ответственного. Ну и так далее пока есть задачи или есть время в спринте (количество разработчиков * рабочее время спринта). Забивая спринт подзавязку, они приступают к работе над ним. Скрэммастер следит за сроками, производит замены задач из пула на низкоприоритетные задачи спринта в случае острой необходимости, согласовывая время. В итоге скорость разработки, прозрачность и управляемость процесса выходят на совершенно иной уровень, который в проектном производстве невозможно достичь.
sulfur17; SamBadi; +2 Ответить 1
17. Сергей necropunk (necropunk) 5 12.08.16 16:00 Сейчас в теме
Мне кажется или я уже где-то читал эту статью, то ли на сайте кодерлайна, то ли на сайте итрп...
h00k; SamBadi; +2 Ответить 2
18. Андрей К (h00k) 45 12.08.16 16:45 Сейчас в теме
(17) necropunk,
Мне кажется или я уже где-то читал эту статью

Не кажется ;)

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


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

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

Насчет заказчиков, с ними работа конечно очень сложна. Даже бывшие разработчики из франчайзи, становясь заказчиком, начинают продавливать сроки и цену, торгуясь за свои бюджеты. Люди же далекие от разработки ПО, похоже, не всегда понимают, что закупка сена и заказ на разработку ПО принципиально разные вещи. Тут уж имеем, что имеем.
23. bulpi bulpi (bulpi) 113 12.08.16 23:31 Сейчас в теме
Да ерунда все это. Я говорю заказчику : я точно сделаю работу. Цену скажу, когда сделаю. По соотношению цена - качество мне никто в обозримом пространстве не конкурент. Не хочешь - свободен, за мной очередь стоит. Сделал, не устраивает цена - свободен навсегда. Но такой поход годится только в том случае, если есть железобетонная репутация и уверенность в себе. А это приходит с годами и десятками внедренных проектов за низкие цены.
vasiliy_b; Mortiferus; unpete; +3 Ответить 1
24. Александр Дмитриев (МимохожийОднако) 117 13.08.16 08:55 Сейчас в теме
Можно долго согласовывать и торговаться с Заказчиком. Но если ты не профи, а профан в работе, то это всё не поможет.
25. Sergey Andreev (starik-2005) 1135 13.08.16 09:49 Сейчас в теме
Какие, смотрю, крутые спецы собрались! Идите к нам работать, а то работы - море просто!
26. Петр Ивакин (Petr54-ru) 49 13.08.16 12:51 Сейчас в теме
(21) Yashazz,

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


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

Есть еще один забавный момент - Кто несет большие риски, заказчик или исполнитель? В очень многих случаях, исполнитель рискует куда больше. Например, в случае провала проекта исполнитель может вообще ничего не получить, или например вернуть авансы и выплатить неустойку. И вместе с выплаченной неустойкой и возвартом авансов вылететь в трубу. Не раз приходилось сталкиваться с такими прецедентами.
27. Максим Гончаров (maxx) 608 13.08.16 18:31 Сейчас в теме
Часто сталкиваюсь с такой ситуацией по оценке задач в проектах.
Заказчика интересует сумма проекта. Проект - это список задач. Заказчику нужно сказать сколько это будет стоить. На этом этапе со стороны Заказчика по сути нет людей, которые могли детально расписать нюансы всех задач. Эти люди в принципе есть, но т.к. проекта ещё нет, нет приказа директора о назначение ответв.лиц за проект, то все очень пассивны и инертны. Но проект упускать не хочется, т.к. есть перспектива получение или опыта или развитие направления. В итоге делаешь грубую оценку. Получаем сумму проекта и очень часто Заказчик теперь проводит эту сумму через процедуру конкурса. Потом когда конкурс выигран и можно начинать работать, все лица со стороны Заказчика "просыпаются" и начинает вылазить куча нюансов.

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

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


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

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

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

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

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

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

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

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

Тут надо две вещи понимать. Во-первых, в любом случае много шансов облажаться с оценкой трудозатрат, А во-вторых, есть у инновационных задач есть особая ценность, например выход за деньги заказчика в новую область компетенции или опять же за деньги заказчика случается "пилотник" и выходишь на новый рынок с новыми возможностями. Я например люблю такие инновационные задачи.
AlenaR; sulfur17; TreeDogNight; +3 Ответить 1
34. Максим Гончаров (maxx) 608 14.08.16 11:29 Сейчас в теме
(30)
Вы выполнили работы в объеме ТЗ. По факту, с вас трясут объем неоплаченной работы по реализации того, чего в ТЗ не было

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

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

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

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



sulfur17; +1 Ответить
35. борян петров (TODD22) 16 14.08.16 13:08 Сейчас в теме
(33) Petr54-ru,
Я в таких случаях беру паузу и объясняю что ничего похожего не делал и что мне нужное некое конкретное время для оценки работы.

Это при условии что заказчик готов платить за процесс. Заказчики то же умные пошли... И хотят покупать готовые решения, а не процесс.
36. Михаил Ражиков (tango) 475 14.08.16 13:56 Сейчас в теме
(С) Альберт Великий, Libellus de Alchimia

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

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

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

Если же, напротив, ты будешь иметь успех, они постараются задержать тебя в плену, где ты будешь работать им на пользу, не имея возможности уйти. Считай, что лишь из-за собственных слов и твоих собственных рассуждений ты попался в ловушку.
Sure; Andrsan; AlmazBur01; intekoserg; user_2010; TreeDogNight; +6 Ответить 1
37. Сергей Коцюра (CheBurator) 3403 14.08.16 18:23 Сейчас в теме
(35) а всеразработчики тоже умные
Все шире и шире продают процесс
38. Петр Ивакин (Petr54-ru) 49 15.08.16 05:45 Сейчас в теме
(35) TODD22,
Это при условии что заказчик готов платить за процесс. Заказчики то же умные пошли... И хотят покупать готовые решения, а не процесс.


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

Продавать процесс хорошо, когда специфика клиента настолько кривая, что нет нормального готового решения или готовое решение станет "костылем" для всего их остального ПО и заказчик стоит перед выбором - или "допилить" их конфигурацию, или разводить у себя "зоопарк" из конфигураций. Так тоже бывает.
39. Александр Зелёнкин (al_zzz) 37 17.08.16 09:01 Сейчас в теме
Моя адекватная оценка тз - это компромисс между моей ленью и жадностью заказчика.
40. Sergey Andreev (starik-2005) 1135 17.08.16 22:50 Сейчас в теме
(36) tango,
Не выходи из комнаты, не совершай ошибку.
Зачем тебе Солнце, если ты куришь Шипку?
За дверью бессмысленно все, особенно -- возглас счастья.
Только в уборную -- и сразу же возвращайся.

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

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

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

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

Не будь дураком! Будь тем, чем другие не были.
Не выходи из комнаты! То есть дай волю мебели,
слейся лицом с обоями. Запрись и забаррикадируйся
шкафом от хроноса, космоса, эроса, расы, вируса.
41. v i (vis_tmp) 27 24.08.16 09:53 Сейчас в теме
(25) starik-2005, "к нам работать" - это куда?
42. Sergey Andreev (starik-2005) 1135 24.08.16 10:21 Сейчас в теме
(41) vis_tmp, считай, что это первый вопрос на собеседовании ))
43. v i (vis_tmp) 27 24.08.16 14:54 Сейчас в теме
44. Sergey Andreev (starik-2005) 1135 24.08.16 17:31 Сейчас в теме
(43) vis_tmp, ну тогда это не для Вас.
45. Xolli Xolli (Xolli) 03.09.16 15:38 Сейчас в теме
какой будет второй вопрос?
46. Виктор Александров (docerman) 42 21.09.16 11:01 Сейчас в теме
Я пользовался простым способом. Если брать пример из статьи максимум 100 часов, минимум 6 часов, то формула оценки такая - среднее значение (100 + 6)/2 = 53. У автора статьи получилось 49, почти как у меня. Только аргументация у меня как Шарикова - взять все и поделить - но такая оценка у меня всегда получалась наиболее близкой к истине.
47. Павел Филатов (biimmap) 2 22.09.16 11:21 Сейчас в теме
Автору спасибо за полезную статью. но я работаю по факту или на окладе. Ну их всех со своими оценками... А сейчас вышли ЗУП 3.0 и ЕРП как можно прогнозировать когда ты ни разу не копался в коде этих конфигураций))) Статья хорошая, но как спрогнозировать то, чего ты вообще не знаешь. вот это было бы интересно понять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

Берегите себя! Оценивайте задачи и свои силы адекватно!
Olenevod; Sure; +2 Ответить
51. Василий Майоров (WasiliyMay) 8 11.03.17 12:35 Сейчас в теме
(23)Вы, видимо, забыли уточнить, что выполняете очень мелкие работы. Ни один человек с опытом не станет работать на таких условиях. Представьте небольшой проект, хотя бы месяц, по окончании которого вам говорят, что нас не устраивает цена. Вы развернетесь и уйдете? Оценивая работы, вы в первую очередь защищаете себя от будущих проблем
52. Евгений (user643267_eturin) 30.03.17 14:27 Сейчас в теме
Считаю, кроме всего прочего не стоит забывать про старый добрый SMART. Ведь оценка это как раз буква "M". Если вы четко определились с остальными: целью (S), инструментами (A), оптимальным способом достижения ® и сроками (T) то дать оценку, это как в поле чудес слово отгадать с одной закрытой буквой.
Оставьте свое сообщение