| Дополнение к статье "Как оценивать задачи программисту 1С" | ||
|
Теперь вернёмся к страхам. Страхи переоценить и недооценить задачи появляются не на пустом месте. Заказчики иногда выражают недовольство оценкой в категоричной форме с переходом на личности. Почти всем в нашем деле знакома обратная ситуация, когда несколько дней работаешь бесплатно, подгоняемый недовольным клиентом, что с задачей на восемь часов "копошатся" третьи сутки. Негативный опыт формирует страх ошибиться в дальнейшем, т.к. наш мозг работает по довольно примитивной схеме запоминания паттернов поведения. Чтобы не повторить подобные ошибки, некоторые вообще отказываются давать оценки заранее. Считаю, что это самый простой и неверный выход из ситуации. |
||
| Теперь перейдём к путям решения данной проблемы. Борьбу со страхами, которые не позволяют трезво и аргументированно подойти к оценке, надо начинать с чего-то приятного. Например, с верхней границы вилки оценки задачи. | ||
| Когда мне говорят, что не могут оценить задачу даже вилкой я обычно сначала уточняю: "за миллион часов сделаешь?". На что чаще всего получаю утвердительный ответ и сомнение в моей адекватности. После того как с "небом" мы определились стоит определиться с "землёй". Следующий вопрос: "а за два часа?". На этот вопрос получаю предсказуемое "Нет", т.к. в противном случае ко мне не обратились бы за помощью. Далее играя в "больше, меньше", вилки сокращаются и получается вилка, которую назовём первичной. | ||
|
Для примера, попытаемся оценить задачу "Надо разработать обработку загрузки поступлений товаров и услуг в "1С:Бухгалтерия предприятия" из xml файлов, выгруженных из другой программы". В текущей постановке (а именно так чаще всего приходят задачи от заказчика) совершенно не ясно, сколько это будет стоить, но первичную вилку сможет дать практически любой программист, знакомый с "1С:Бухгалтерия". Скажем, она будет от 6 до 100 часов. Это уже что-то. |
||
|
С нижней оценкой всё понятно - она рассчитана методом "если повезет". А как возникает верхняя граница оценки? Выясняется, что верхняя граница возникает из-за того, что исполнитель, например, толком не понимает, что делать, или из-за того, что заказчик ранее постоянно уточнял свои требования к интерфейсу по уже оцененной и выполненной задаче. Конкретных причин верхней оценки может быть много, но самая главная: |
||
|
"непонимание, что нужно делать".
|
|
Если непонимание связано с тем, что Вы никогда не работали с ЗУП, а задача "сделать так, чтобы расчетные листки формировались корректно", то первое, о чём стоит подумать – это отказ от данной задачи. Если в силу определенных обстоятельств отказ практически невозможен, будьте готовы, что комфортную оценку вы не получите и это неплохо, т.к. опыт тоже дорого стоит. Чтобы минимизировать риски, обращайтесь за помощью к тем, кто имел опыт решения подобных задач. Остальные причины верхних границ нужно прописывать в конкретных требованиях или ограничениях, а также снимать риски вопросами. С ограничениями всё просто. На моей практике заказчик всегда адекватно относился к большому перечню ограничений. |
||
|
Накапливайте свой перечень ограничений от каждой задачи, т.к. зачастую в разных задачах одни и те же риски.
|
||
|
В примере с загрузкой из xml в оценку можно включить:
|
||
|
В ограничениях прописать, что в оценку не входят:
|
||
|
Константин Вальков, руководитель отдела внедрения ООО “Кодерлайн” |
