Оценивать задачу всегда сложно. Постараюсь описать именно свой субъективный опыт в этом вопросе, чтобы помочь коллегам решить подобный вопрос.
Сразу оговорюсь, у меня до сих пор не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, и только о технической оценке. Иногда по «политическим» мотивам техническую оценку необходимо уменьшить или увеличить, но данный вопрос не будем рассматривать. Также в статье не рассматривается вопрос торгов по оценке и переоценка в процессе выполнения задачи.
В нашей работе приходиться оценивать задачи с некоторыми неизвестными факторами. Чем их больше, тем больше мозг «бунтует» и сопротивляется решению вопроса. Обычно сопротивление мозга проявляется в беспокойстве, страхах, т.к. с одной стороны возникает страх завысить оценку и показаться некомпетентным или остаться без задачи или даже без клиента, с другой стороны страшно не учесть «подводных камней» и в будущем сидеть часами, а то и днями, делая неоплачиваемую работу.
Соответственно, чтобы оценить задачу хорошо, надо исключить два вышеуказанных страха. Но сначала надо определиться, что же означает оценить задачу «хорошо».
В моем понимании хорошая оценка – это ясная оценка, которую всегда можно аргументировать и которая позволяет комфортно приступить к работе (для каждого конкретного исполнителя это субъективное понятие). То есть, если заказчик или менеджер считают, что Вы оценили задачу слишком дорого, это совершенно не означает того, что задача оценена плохо. При этом, как правило, чем меньше опыта у сотрудника, тем меньшую оценку он будет давать, переоценивая свои возможности, попадаясь в ловушку первого страха – показаться некомпетентным. С точки зрения заказчика эта оценка будет хорошей.
Хорошей оценкой в этой статье будет считаться ясная и комфортная оценка для исполнителя.
Теперь вернёмся к страхам. Страхи переоценить и недооценить задачи появляются не на пустом месте. Заказчики иногда выражают недовольство оценкой в категоричной форме с переходом на личности. Почти всем в нашем деле знакома обратная ситуация, когда несколько дней работаешь бесплатно, подгоняемый недовольным клиентом, что с задачей на восемь часов «копошатся» третьи сутки. Негативный опыт формирует страх ошибиться в дальнейшем, т.к. наш мозг работает по довольно примитивной схеме запоминания паттернов поведения. Чтобы не повторить подобные ошибки, некоторые вообще отказываются давать оценки заранее. Считаю, что это самый простой и неверный выход из ситуации.
Теперь перейдём к путям решения данной проблемы. Борьбу со страхами, которые не позволяют трезво и аргументированно подойти к оценке, надо начинать с чего-то приятного. Например, с верхней границы вилки оценки задачи.
Когда мне говорят, что не могут оценить задачу даже вилкой, я обычно сначала уточняю: «За миллион часов сделаешь?». На что чаще всего получаю утвердительный ответ и сомнение в моей адекватности. После того как с «небом» мы определились, стоит определиться с «землёй». Следующий вопрос: «А за два часа?». На этот вопрос получаю предсказуемое «Нет», т.к. в противном случае ко мне не обратились бы за помощью. Далее играя в «больше, меньше», разрыв сокращается и получается вилка, которую назовём первичной.
Для примера, попытаемся оценить задачу «Надо разработать обработку загрузки поступлений товаров и услуг в 1С:Бухгалтерию предприятия из xml файлов, выгруженных из другой программы». В текущей постановке (а именно так чаще всего приходят задачи от заказчика) совершенно не ясно, сколько это будет стоить, но первичную вилку сможет дать практически любой программист, знакомый с 1С:Бухгалтерией предприятия. Она будет скажем: от 6 до 100 часов. Это уже что-то.
С нижней оценкой всё понятно — она рассчитана методом «если повезет».
А как возникает верхняя граница оценки? Выясняется, что верхняя граница возникает из-за того, что исполнитель, например, толком не понимает, что делать, или из-за того, что заказчик ранее постоянно уточнял свои требования к интерфейсу по уже оцененной и выполненной задаче. Конкретных причин верхней оценки может быть много, но самая главная: «непонимание, что нужно делать».
Если непонимание связано с тем, что вы никогда не работали с ЗУП, а задача «сделать так, чтобы расчетные листки формировались корректно», то первое, о чём стоит подумать – это отказ от данной задачи. Если в силу определенных обстоятельств отказ практически невозможен, будьте готовы, что комфортную оценку вы не получите, и это неплохо, т.к. опыт тоже дорого стоит. Чтобы минимизировать риски, обращайтесь за помощью к тем, кто имел опыт решения подобных задач. Остальные причины верхних границ нужно прописывать в конкретных требованиях или ограничениях, а также снимать риски вопросами.
С ограничениями всё просто. На моей практике заказчик всегда адекватно относился к большому перечню ограничений. Накапливайте свой перечень ограничений от каждой задачи, т.к. зачастую в разных задачах одни и те же риски. В примере с загрузкой из xml, в оценку можно включить разработку обработки, написание инструкции, а в ограничениях прописать, что в оценку не входят: консультации пользователей по работе с обработкой; настройка ролей и интерфейсов; доработка в связи с изменениями конфигурации заказчиком или третьей стороной; доработка из-за изменения формата xml.
Задать вопросы и запросить дополнительные детали сложнее. Здесь опять появляется опасение показаться некомпетентным. Порой совершенно безобидный вопрос расценивается как отсутствие знаний. Постарайтесь перебороть этот страх. Вопросы задавать можно и нужно.
Один из самых высококвалифицированных программистов, с которым мне посчастливилось работать, начинал задавать самые простые вопросы, когда у него появлялась новая задача. Как правило, его собеседник сперва снисходительно отвечал на явно пустяковые вопросы, но чем дальше, тем больше понимал, как много для него самого неясностей. Рассказывали случай, как целый отдел методологов крупной компании взял паузу на неделю, чтобы ответить на вопрос, поставленный этим программистом. Фиксируйте все ответы, даже неадекватные ответы.
Например, если в шаблоне и примере данных нет необходимых для загрузки договоров полей, на вопросы «Есть ли данные по договору в другой учетной системе, аналоге документа поступления? Могут ли специалисты другой учетной системы дополнительно выгрузить номер и дату договора?», вам может быть дан ответ «Мы не программисты и этого не знаем». Для вас это означает, что оценку можно аргументированно повысить, так как дополнительно, с помощью заказчика (это отдельно прописать) предстоит анализ и общение со специалистами другой учетной системы.
Непрофессионально обращаться с одним и тем же вопросом дважды, ответы не должны теряться. Для фиксации ответов на устные вопросы после разговора обязательно отправьте письмо с ответами и просьбой подтвердить их. В дальнейшем эти ответы позволят вам аргументировать оценку.
В примере с разработкой загрузки из xml, очевидно, что первым делом нужно запросить шаблон xml файла, а также примеры выгрузок и конфигурацию заказчика.
После просмотра примеров возникают вопросы, ответы на которые напрямую влияют на оценку, например: «Надо создавать новый элемент справочника «Контрагенты», если по указанным в файле полям поиска (допустим «ИНН, КПП») контрагент не найден или выдавать ошибку? Надо ли создавать новые элементы справочников «Номенклатура», если по полю поиска (допустим «Код в другой системе учета») элементы не найдены? Поступление товаров и услуг в нашем случае формируется только на товары, или материалы и услуги тоже могут присутствовать? Откуда брать недостающую информацию для создания элементов справочников «Контрагенты», «Номенклатура»? Обработка должна запускаться вручную или автоматически по расписанию? Расчеты с контрагентами ведутся только в рублях или в условных единицах и иной валюте также?»
Составить требования еще сложнее, чем задать вопросы. Иногда требования не ясны как заказчику, так и исполнителю. Вносить ясность – это значит тратить время, а будет оно оплачено или не будет, еще вопрос. В таких ситуациях нужно попробовать проговорить с заказчиком оплатить постановку задачи. Порой заказчик считает, что исполнитель не профессионален, если не понимает требования. Это зачастую правда и здесь опять же стоит трезво оценить: браться за задачу или нет. Если при всех подводных камнях, которые по ряду обстоятельств нельзя оценить на берегу (на то они и подводные), вы все равно считаете целесообразным взяться за задачу, то беритесь и пусть ваша оценка будет неверная. Риски, на которые вы идете в таком случае – осознанные.
Если требования вам понятны и очевидны, не поленитесь их прописать. Другим участникам процесса они могут быть не понятны. Недопонимание – ключевая проблема в нашей работе. Как правильно писать требования – это тема отдельной статьи, но писать их нужно обязательно.
После того как требования определены, разложите задачу на подзадачи. Чем больше, тем лучше. Стоит также указать подзадачи, необходимые для сдачи работ, например: составление контрольного примера тестирования, тестирование согласно контрольному примеру. Также стоит указать перечень подзадач, которые должен выполнить заказчик для обеспечения возможности вашей работы, например: утверждение формата выгрузки, нормализация НСИ. Будьте готовы, что после выделения подзадач, оценка может существенно поменяться, это нормально. Могут также появиться новые вопросы и требования.
Подзадачи для нашего примера:
- Согласование с разработчиками другой учетной системы (через заказчика) полей поиска элементов справочника «Договоры контрагентов» и изменение формата выгрузки: 2 — 8 часов
- Утверждение формата выгрузки из другой учетной системы — 0 часов (работа заказчика)
- Разработка функционала для сопоставления текущих договоров с полями, выгруженными из другой учетной системы — 0 — 8 часов.
- Сопоставление договоров 1С и кодов другой учетной системы — 0 часов (работа заказчика)
- Подготовка шаблона Excel для ручного заполнения соответствий кодов другой учетной системы и номенклатуры (иерархически): 2 часа
- Сопоставление номенклатуры 1С и кодов другой учетной системы — 0 часов (работа заказчика)
- Загрузка значений дополнительного свойства «Код другой учетной системы» справочника «Номенклатура» из Excel: 2 — 4 часа
- Разработка алгоритма создания элементов справочника «Номенклатура» по коду другой учетной системы и наименованию: 2 часа
- Разработка обработки загрузки поступлений товаров и услуг из xml: 8 — 12 часов
- Разработка регламентного задания (для автоматического запуска по расписанию) — 2 часа
- Подготовка инструкции (по настройке расписания и запуску обработки) — 4 часа
- Составление контрольных примеров (один документ на каждый пример), подготовка тестовой среды: поступление без НДС, поступление с НДС 18%, поступление с ошибкой по контрагенту (не найден по ИНН/КПП), поступление с созданием новой номенклатуры: 2 — 3 часа
Тестирование обработки согласно контрольным примерам, составление протокола тестирования: 4 часа
После того как будут получены ответы на вопросы, прописаны конкретные требования и ограничения, а также задача будет разложена по подзадачам — вилка оценки скорее всего будет приемлемой. В нашем примере: 28 — 49 часов.
Не надо бояться, если вилка по прежнему с большим разбросом, главное, что вы сами понимаете причину разброса и можете её аргументировать.
Если заказчик настаивает на четкой оценке, выставляйте верхнюю границу. Страхи исчезнут сами, т.к. на любой вопрос по оценке вы будете готовы предоставить аргументы.
Итак, выдержка по оценки задач:
1. Прикиньте максимум и минимум затрат. Неважно, что оценки могут отличаться в разы
2. Задавайте вопросы, фиксируйте ответы
3. Прописывайте ограничения
4. Прописывайте конкретные требования
5. Разделите задачу на подзадачи
6. Скорректируйте первоначальную вилку, не стремитесь, чтобы она обязательно была узкой. Стремитесь к тому, чтобы любой пункт оценки вы смогли аргументировать
7. Не бойтесь ошибаться в оценке, если задачу целесообразно решить по отличным от «меркантильных» мотивам
Тем, кому интересно изучить данный вопрос подробнее, советую почитать книгу Стива Макконнелла «Сколько стоит программный проект».
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Есть три вида принципиально разных по объему задач:
1. Те, задачи которые делаются за пару часов;
2. Те проекты, которые делаются за выходные;
3. И те проекты, которые не делаются за выходные.
Это три абсолютно разных мира задач, и под каждый вид нужна своя отдельная методология.
В умных книжках подробно описаны масса различных методологий разработки, тысячи их, практически все методики предлагают рабочие методики оценки трудоемкости, бери подходящие по задачам и команде методики, пользуйся, какие проблемы?
(1) Petr54-ru, отчасти согласен, что от объема задачи напрямую зависит методика оценки.
Но какая-та градация у Вас выборочная, если придраться к вашей формулировке, то проект на неделю и на 5 лет находятся в одном «мире задач», а это не так.
Отвечаю на ваш вопрос: проблема в том, что тысяча книг написано, а коллеги разработчики, все равно избегают браться за задачу когда их просишь предварительно оценить, потому что, испытывают дискомфорт из-за возможности ошибиться. Пусть это будет тысяча первая статья, но если кому-то она поможет не отказаться от задачи и сделать её не себе в убыток, то цель достигнута.
В методологии SCRUM для оценки задач для спринта используется технология покера планирования, когда независимо друг от друга разработчики оценивают задачу, а потом тех, кто дал экстремальные оценки, спрашивают, почему. В итоге таким образом рождается вполне реальная оценка, которая, исходя из практики применения данного подхода, оказывается куда точнее, чем обычная оценка.
Понравилось. Невнятные пожелания преобразуются в четкие требования.
(3) starik-2005, это когда есть ТЗ или внятные требования. А когда нет?
(2)
Совершенно верно, такие проекты относятся к одному миру, поскольку для этих проектов в принципе невозможно дать приблизительную оценку трудоемкости и необходимо провести предпроектные работы в результате которых будет например получена согласованная спецификация и примерная оценка трудоемкости. И да, «проект на 5 лет» нужно делать исходя из соображений «слона нужно есть по частям» — нарезаем «слона» на «стейки» в виде проектов съедобного объема и «поедаем».
В этом месте есть проблема, которая в основном обусловлена нашей 1С-ной спецификой. Если на стороне заказчика есть ИТ-специалисты, способные предоставить разработчикам внятное техзадание, то все хорошо. Обычно на стороне заказчика таких людей нету. Можно провести анализ, написать и согласовать рабочее техзадание, а заказчик возьмет это ТЗ, скажет спасибо и без проблем найдет разработчика, который за небольшие деньги по готовому техзаданию сделает все, что нужно. Можно пойти по пути, что сделать первую часть проекта «предпроектные работы» — исследование, сбор требований, проектирование, согласование — а на выходе будет согласованное ТЗ, за который заказчик заплатил и с которым заказчик может пойти к любому исполнителю. С другой стороны, заказчик может стоять на позиции, что ему не нужно техзадание, ему нужно решение проблемы и за всякие левые бумажки он платить не будет. И тогда самый разумный подход — нарезать большую задачу на «микропроектики» из серии — «мы это сделаем за выходные + » в которых объединять логически связанные сценарии использования (use cases), чтобы можно было спокойно, на основании своих экспертных оценок выводить трудоемкость работы, сроки сдачи и стоимость, далее умножать эти показатели на два и выставлять заказчику. Если ожидания заказчика существенно ниже наших рассчетов — то либо заказчик изменит свои ожидания, либо это просто не наш заказчик.
Тут, относительно трудоемкости важно понимать две вещи:
1. Производительность двух программистов с одинаковым по времени опытом работы может отличаться в разы.
2. У программиста может быть в загашничке старая разработка которая с минимальными затратами может быть адаптирована под новую задачу (тот самый reuse).
Оценка у меня всегда зависит от клиента и от цены за час. Лояльный — моя примерная оценка + половина от нее. Низкая цена за час — моя оценка плюс еще столько же. Бывает и за ту же оценку, если клиент новый или жадный. В итоге, даже, если недооценка, выходит нормально. С проектами тяжелее. Так как его надо продать и ты новичок на рынке — оценка низкая. У тебя лобби — оценка завышенная. Бывает объем по проекту растет, тут зависит от того, как сможешь обосновать повышение стоимости проекта. На проектах фактическая оценка, по опыту работы, нужна для расчета себестоимости проекта.
(3) starik-2005, Методика хорошая. Но оценка задачи не всегда быстрое дело и собрать «игроков за покерным столом» дело довольно хлопотное и последних надо как-то мотивировать.
Как по мне: адекватная оценка приходит с опытом. Когда я ещё работал во франче начальник (не программист) мои программистские задачи оценивал всегда более адекватно нежели я. Просто у него в этом было больше опыта, он выслушивал задачу + мою оценку и выдавал правильную оценку.
Причём заметил особенность: моя оценка обычно в 1,5 — 2 раза меньше действительно затраченного времени. Когда я свою оценку сразу озвучивал умножая на 1,5 начальник соглашался (хотя не знал что я умножил) и я обычно укладывался в эти сроки.
Был даже случай когда простенькую переделку отчета на 2 часа я заложил 4 часа (никогда так раньше не делал на столь малой работе, но именно тут что-то «щёлкнуло»). И не прогадал: работу то я сделал за 2 часа, но сдавал я её ещё 2 часа: были нюансы/вопросы заказчика, фактически не совсем по теме задачи, переделкой отчета во вторые 2 часа не занимался.
А так нашу Программистскую работу трудно оценить (даже постфактум). Разве ни у кого не бывало, когда за первую половину дня написал сотни строк кода, а во второй половине дня «встрял» и по факту за вторые 4 часа написал пару строк? Порой и правда бывает, что «90 процентов работы делается за 10 процентов времени»…
(3) starik-2005, поставил +1. Хотел только добавить, что бывают задачи, которые реально оценить сложно. Да, и нету на это времени. Инциденты не рассматриваются в рамках спринта. С клиентом лучше договорится по факту затраченного времени на их выполнение.
(3) starik-2005,
Ага и тот кто дал экстремально минимальные оценки(времени, трудозатрат ит д) сам выполняет задачу.
особенно неадекватные
давным-давно, во времена позднего фриланса, я предлагал обратиться к франчайзям с обещанием сделать эту задачу за выставленную франчайзями цену
указания заказчика на НДС и т.п.разницы игнорировал: нал, значит нал, хотите НДС — идите к франям
(7) все зависит от процессной зрелости компании, которая занимается внедрением. Если это профессионал-одиночка, то, конечно, риски для заказчика высокие, но ценник кажется небольшим. Если это компании со зрелыми процессами, то риск минимальный, т.к. озвученный бюджет и временные сроки проекта будут соблюдены.
Отсюда как бы легко и просто вытекает то, что с серьезными заказчиками крайне редко будет работать какой-то такой одинокий волк, удел которого мелкие компании с маленькими бюджетами и бесконечной рутиной. И этот разработчик — это их риск, про который они вообще ничего не знают из-за незрелости риск-менеджмента и невысокой капитализации компании в целом, не позволяющей им привлекать специалистов, компетентных в данной области, ибо оная не кажется им важной. Крупные компании работают двумя путями: сокращают риски или обогащают ответственных сотрудников за счет купленных тендеров. Но мелкая компания тендер все-равно не купит, так что риски в любом случае учитываются.
(10) TODD22, это, видимо, в Вашем колхозе так. Колхозников не жалко.
(13) starik-2005, и в очень больших компаниях на очень больших проектах ответственность за оценку задач ложится на конечного человека. В статье речь идет именно про оценку программиста, а не технического руководителя проекта, архитектора, ответственного за блок или иного ключевого лица на проекте.
Даже оцененные заказчиком, расписанные ответственным задачи или дают программисту на оценку, или программисту надо понять возьмется ли он делать за указанные часы или в указанные сроки (в конечном итоге те же часы для руководства). В такой ситуации, программист практически никогда не несёт рисков за неверную постановку, скорее всего ему закроют часы сверх оговоренного если он приведет хоть одну причину увеличения трудозатрат. Но, даже в такой ситуации возникают конфликты когда, например, руководитель разработки пытается надавить на разработчика и заставить его сделать что-то бесплатно (сверхурочно) или, что чаще в моей практике, разработчик безропотно соглашается, а потом постоянно, без аргументов, сдвигает сроки, что портит репутацию программиста.
Программисту, в конечном итоге, всегда надо ясно представлять себе что и как делать, уметь объяснить, что мешает ясной постановке, понимать, что прояснение постановки это тоже работа.
(15) ну тут все упирается в опыт программиста по оценке. Если он подобную задачу делал — проблем нет. Если не делал — тогда как он поймет, сколько времени на это понадобится? Но я говорю о другой технологии работы, когда все загоняются не в проект, а в спринт-команды по пять-семь человек. Это один из вариантов гибкой методологии разработки. Суть в том, что группа разработчиков со скрам-мастером выбирают из пула задач те, которые они будут реализовывать в этот спринт. Алгоритм прост: пока в пуле задач есть задачи, выбирают оттуда максимально приоритетную задачу, проводят покер планирования, определяются окончательно со временем, засовывают задачу в спринт и определяют ответственного. Ну и так далее пока есть задачи или есть время в спринте (количество разработчиков * рабочее время спринта). Забивая спринт подзавязку, они приступают к работе над ним. Скрэммастер следит за сроками, производит замены задач из пула на низкоприоритетные задачи спринта в случае острой необходимости, согласовывая время. В итоге скорость разработки, прозрачность и управляемость процесса выходят на совершенно иной уровень, который в проектном производстве невозможно достичь.
Мне кажется или я уже где-то читал эту статью, то ли на сайте кодерлайна, то ли на сайте итрп…
(17) necropunk,
Не кажется 😉
Сам вчера столкнулся с сильным чувством дежа-вю и хотел возмутиться, но потом нашел статью которую я видел раньше и сравнив авторов успокоился 😀
(17) necropunk, + за внимательность. На сайте Кодерлайна (работаю там) немного модифицированную (разделенную по блокам) коллегами редакторами версию статьи выложили.
(16) starik-2005, звучит довольно заманчиво. Надо попробовать на практике.
Чего никогда не понимал, как подобные самоочевидные вещи, изложенные в статье, могут ещё вызывать интерес. Тем более выраженный в таком рейтинге публикации… Это же всё давно дважды-два-четыре, что нового-то сказано?
А насчёт рисков — знаете, тут недавно представитель одного довольно крупного заказчика заявил: «наши риски — это то, что мы согласимся на более высокую цену, которую предлагаете вы, чем на ту, что другие участники конкурса». Т.е. человек вообще не понимает, что такое риски проекта, а именно он и выбирает автоматизатора. Ну и о чём мы все тут говорим?..
(21) Yashazz, Есть книга Роберта Кийосаки «Бедный папа, богатый папа». Советую почитать. Там на протяжении большого количества страниц расписывается одна мысль: «чтобы денег было больше: надо меньше тратить и больше зарабатывать». Были еще мысли про инвестиции, но они, по-моему, не очень пригодны для нашей страны. В своё время эта банальная книга с самоочевидными вещами мне помогла гораздо больше чем сложные книги. Надеюсь, что кому-то поможет и эта очевидная статья.
Насчет заказчиков, с ними работа конечно очень сложна. Даже бывшие разработчики из франчайзи, становясь заказчиком, начинают продавливать сроки и цену, торгуясь за свои бюджеты. Люди же далекие от разработки ПО, похоже, не всегда понимают, что закупка сена и заказ на разработку ПО принципиально разные вещи. Тут уж имеем, что имеем.
Да ерунда все это. Я говорю заказчику : я точно сделаю работу. Цену скажу, когда сделаю. По соотношению цена — качество мне никто в обозримом пространстве не конкурент. Не хочешь — свободен, за мной очередь стоит. Сделал, не устраивает цена — свободен навсегда. Но такой поход годится только в том случае, если есть железобетонная репутация и уверенность в себе. А это приходит с годами и десятками внедренных проектов за низкие цены.
Можно долго согласовывать и торговаться с Заказчиком. Но если ты не профи, а профан в работе, то это всё не поможет.
Какие, смотрю, крутые спецы собрались! Идите к нам работать, а то работы — море просто!
(21) Yashazz,
Заказчик этот, как надо все прорубает. Он для себя оценил риски проекта, в виде некоей суммы, которая будет как-то соответствовать его потерям, если проект не будет реализован. Каким образом он может снизить свои риски? Выбрать самого компетентного исполнителя. Он нашел самого компетентного исполнителя в лице вашей конторы, собственно разница между вашей ценой и самой минимальной и будет его платой за риск. Если эта «дельта» меньше той цифры, в которую он оценил риски проекта, то он молодец и все правильно сделал.
Есть еще один забавный момент — Кто несет большие риски, заказчик или исполнитель? В очень многих случаях, исполнитель рискует куда больше. Например, в случае провала проекта исполнитель может вообще ничего не получить, или например вернуть авансы и выплатить неустойку. И вместе с выплаченной неустойкой и возвартом авансов вылететь в трубу. Не раз приходилось сталкиваться с такими прецедентами.
Часто сталкиваюсь с такой ситуацией по оценке задач в проектах.
Заказчика интересует сумма проекта. Проект — это список задач. Заказчику нужно сказать сколько это будет стоить. На этом этапе со стороны Заказчика по сути нет людей, которые могли детально расписать нюансы всех задач. Эти люди в принципе есть, но т.к. проекта ещё нет, нет приказа директора о назначение ответв.лиц за проект, то все очень пассивны и инертны. Но проект упускать не хочется, т.к. есть перспектива получение или опыта или развитие направления. В итоге делаешь грубую оценку. Получаем сумму проекта и очень часто Заказчик теперь проводит эту сумму через процедуру конкурса. Потом когда конкурс выигран и можно начинать работать, все лица со стороны Заказчика «просыпаются» и начинает вылазить куча нюансов.
В итоге получаем вилку: с одной стороны, Заказчику нужна для оценки сумма проекта чтобы понять вообще о каком порядке сумм идёт речь, но на этапе согласовании сметы ещё трудно всё оценить; с другой стороны, когда Сумма проекта уже зафиксирована, границы задач начинают расширяться и мы можем попасть на кучу бесплатной работы.
(27) maxx,
А если заказчик воспринял идею варки супа из топора как руководство к действию, то исполнителя ждет масса интересного.
Есть фундаментальный принцип работы в области — IT — «С чудаками на букву ЭМ не работаем» ибо себе дороже, пусть с ними конкуренты работают. Если на этапе предварительных разговоров мы увидим со стороны заказчика рога или копыта, право лучше отползти и заняться чем-то другим.
Если заказчик вменяем и способен к диалогу, то есть два способа. Тут на первое место выходит работа с ожиданиями клиента. Об эти способы нужно заранее с закзчиком обговорить «на этом берегу», например так — Мы знаем, что в процессе выполнения проектов у ваших людей появится масса «хотелок», которых сейчас в проекте нет. С этими «хотелками» торопиться не надо, поскольку наш опыт говорит о том, что 80% этих «хотелок» не правильные, а когда люди 3-6 месяцев поработают в программе у них появятся совсем другие хотелки — и это будут уже «правильные хотелки». Есть два способа — первый способ мы аккуратно собираем все «хотелки», сдаем вам проект в том виде, как согласованно сейчас, а после сдачи согласуем следующий проект, в котором оперативно все эти «хотелки» реализуем. Либо второй вариант — если ли решаете, что в проект надо нечто в функционал добавить, одновременно с этим вам нужно будет решить что придется из функционала проекта выкинуть. Для наглядности можно привести пример ремонта автомобиля на СТО — пригнал машину тормозные колодки заменить, заодно за эту цену двигатель откапитальте
(28)
Эх, если бы было так всё просто. Очень часто у людей, которые и сбрасывают «хотелки» и отвечают на вопрос: «Исполнители говорят, что проект закончили. Это так?» и вот тут они начинают: «Ну как бы, что-то сделали , всё по ТЗ, но ничего не работает как надо, т.к. много всего не хватает».
(29) maxx,
Либо неправильная технология работы с заказчиком либо, цель заказчика — получить от вас «за рубль паровоз».
В сухом остатке — Вы написали и согласовали ТЗ. Закзчик по вашему ТЗ провел конкурс. Так получилось, что конкурс выиграли вы. В результате появился контракт — за определенную сумму и сроки реализовать ТЗ. Вы выполнили работы в объеме ТЗ. По факту, с вас трясут объем неоплаченной работы по реализации того, чего в ТЗ не было.
Вам надо продумать технологию работы с заказчиком по договору, которая бы исключала такие варианты. Это реально.
(29) maxx, В таких случаях небходимо использовать Тест-кейсы на каждую функцию, описанную в ТЗ, требуя подписи от Ответственных лиц Фирмы-Заказчика. Тогда в случае фраз «но ничего не работает как надо» можно смело указывать на подписанные Тест-кейсы.
Хотелось бы узнать, как Программисту наиболее правильно оценивать задачи «Инновационного типа», с которыми он ещё не встречался, например интеграция с какой-нибудь редкой системой?
(32) TreeDogNight,
Я в таких случаях беру паузу и объясняю что ничего похожего не делал и что мне нужное некое конкретное время для оценки работы. Изучаю доступную информацию по задаче и выкатываю оценку. В оценку вставляю затраты на этот анализ.
Тут надо две вещи понимать. Во-первых, в любом случае много шансов облажаться с оценкой трудозатрат, А во-вторых, есть у инновационных задач есть особая ценность, например выход за деньги заказчика в новую область компетенции или опять же за деньги заказчика случается «пилотник» и выходишь на новый рынок с новыми возможностями. Я например люблю такие инновационные задачи.
(30)
Я с вами согласен во многом. Но все время сталкиваешься с ситуацией недосказанности на начальном этапе.
Пример:
Присылают по электронке печатную форму акта услуг. Посмотрев на нёё, можно сказать что это стандартный акт, который присоветует в бухгалтерии, только в наименование услуге выведен Месяц, за который услуги оказаны, исходя из даты документа. Уточнив всё это, технический специалист понимает, что работы немного изменить описание услуги при подстановки номенклатуры в тч. Оценка технич.специалиста — 1 ч. В договор в тз включена скан-форма печатной документа.
Потом, когда напомню выигран конкурс и кучу другой бюрократии прошло. Выясняется, что всё сложнее.
— содержание услуги может быть разной в зависимости от категории контрагента, при этом номенклатура одна и та же при выписки должна быть
— есть случаи выписки в несколько номенклатур акта, а при печати нужно свернуть до одной строки и одним содержанием
— другие нюансы
Всё это в итоге приводит к тому, что если всё сразу не сделать, выписка документов невозможна.
Это очень упрощенный пример.
Понимаю, что на самом первом этапе нужно всё было это выяснить, но как я говорил и не только я, на это времени иногда нет, особенно у заказчика или он не готов сам всё это подробно обсуждать пока нет с ними договора.
(33) Petr54-ru,
Это при условии что заказчик готов платить за процесс. Заказчики то же умные пошли… И хотят покупать готовые решения, а не процесс.
(С) Альберт Великий, Libellus de Alchimia
Следует быть очень осторожным, особенно тогда, когда работаешь на глазах у твоих хозяев, могущественных властителей — монархов и князей. Две опасности, две беды стерегут тебя.
Если тебе поручено некое златоискательское дело, они не перестанут терзать тебя время от времени расспросами: «Ну, мастер! Как идут твои дела? Когда, наконец, мы получим приличный результат?» И, не дождавшись окончания работы, они станут всячески глумиться над тобой.
В результате тебя постигнут великое разочарование, унижение и великие беды.
Если же, напротив, ты будешь иметь успех, они постараются задержать тебя в плену, где ты будешь работать им на пользу, не имея возможности уйти. Считай, что лишь из-за собственных слов и твоих собственных рассуждений ты попался в ловушку.
(35) а всеразработчики тоже умные
Все шире и шире продают процесс
(35) TODD22,
Если есть готовое решение — надо продавать готовое решение. Нормальный вариант, если разработчик готового решения (типа вендор), даст возможность внедренцу (типа системному интегратору) заработать на продаже лицензий 45-55% и впоследствии двигать дальше это готовое решение. Тогда у внедренца состоится «пилотник» и он дальше сможет за деньги заказчика выйти на новый рынок. Так реально бывает. Если разработчик не хочет придружить системного интегратора, который бы за долю справедливую продвигал бы у себя в регионе его решение — то тогда это просто не ваш клиент.
Продавать процесс хорошо, когда специфика клиента настолько кривая, что нет нормального готового решения или готовое решение станет «костылем» для всего их остального ПО и заказчик стоит перед выбором — или «допилить» их конфигурацию, или разводить у себя «зоопарк» из конфигураций. Так тоже бывает.
Моя адекватная оценка тз — это компромисс между моей ленью и жадностью заказчика.
(36) tango,
Зачем тебе Солнце, если ты куришь Шипку?
За дверью бессмысленно все, особенно — возглас счастья.
Только в уборную — и сразу же возвращайся.
О, не выходи из комнаты, не вызывай мотора.
Потому что пространство сделано из коридора
и кончается счетчиком. А если войдет живая
милка, пасть разевая, выгони не раздевая.
Не выходи из комнаты; считай, что тебя продуло.
Что интересней на свете стены и стула?
Зачем выходить оттуда, куда вернешься вечером
таким же, каким ты был, тем более — изувеченным?
О, не выходи из комнаты. Танцуй, поймав, боссанову
в пальто на голое тело, в туфлях на босу ногу.
В прихожей пахнет капустой и мазью лыжной.
Ты написал много букв; еще одна будет лишней.
Не выходи из комнаты. О, пускай только комната
догадывается, как ты выглядишь. И вообще инкогнито
эрго сум, как заметила форме в сердцах субстанция.
Не выходи из комнаты! На улице, чай, не Франция.
Не будь дураком! Будь тем, чем другие не были.
Не выходи из комнаты! То есть дай волю мебели,
слейся лицом с обоями. Запрись и забаррикадируйся
шкафом от хроноса, космоса, эроса, расы, вируса.
Показать
(25) starik-2005, «к нам работать» — это куда?
(41) vis_tmp, считай, что это первый вопрос на собеседовании ))
(42) starik-2005, А я фрилансер )
(43) vis_tmp, ну тогда это не для Вас.
какой будет второй вопрос?
Я пользовался простым способом. Если брать пример из статьи максимум 100 часов, минимум 6 часов, то формула оценки такая — среднее значение (100 + 6)/2 = 53. У автора статьи получилось 49, почти как у меня. Только аргументация у меня как Шарикова — взять все и поделить — но такая оценка у меня всегда получалась наиболее близкой к истине.
Автору спасибо за полезную статью. но я работаю по факту или на окладе. Ну их всех со своими оценками… А сейчас вышли ЗУП 3.0 и ЕРП как можно прогнозировать когда ты ни разу не копался в коде этих конфигураций))) Статья хорошая, но как спрогнозировать то, чего ты вообще не знаешь. вот это было бы интересно понять.
Приведу пример: я работал в 1С. мой профиль ЗУП. мне дали задачу по казначейству, которая для человека знающего казначейство очень простая. Но я первый раз в глаза увидел ЕРП. А с казначеем ни с одним не знаком лично!
В итоге мне нужно понять 5 моментов:
1. Предметную область (как оценить время на её изучение если ты не знаешь даже рамки этой области)
2. Архитектуру решения ЕРП (вопрос тот же)
3. Функциональность каждого из документов/справочников/регистров (их огромное количество)
4. Сценарии работы пользователей (их в принципе знают только разработчики каждой отдельной подсистемы! и они нигде не описаны)
5. Структура кода (какие способы реализации были применены при программировании интерфейсов, движений, проверок)
Вот я пока не встретил человека который мне смог бы ответить как не зная эти 5 пунктов оценить задачу и как оценить собственно эти 5 пунктов.
Если я это когда-нибудь узнаю, я стану гуру планирования))) А пока всех посылаю и работаю на окладе)))
Главное постановка, если пользователь не может объяснить чего хочет, то и дело не пойдет.
(48) agulaev, если пользователь не может объяснить чего хочет, то обычно даётся оценка на поставку ТЗ. Т.е. за 10 (50, 100 или любая другая цифра) часов специалист внедренец вникнет в задачу, за пользователя составит требования и напишет ТЗ в котором будут уже изложены все аспекты задачи.
(23)Вы, видимо, забыли уточнить, что выполняете очень мелкие работы. Ни один человек с опытом не станет работать на таких условиях. Представьте небольшой проект, хотя бы месяц, по окончании которого вам говорят, что нас не устраивает цена. Вы развернетесь и уйдете? Оценивая работы, вы в первую очередь защищаете себя от будущих проблем
Считаю, кроме всего прочего не стоит забывать про старый добрый SMART. Ведь оценка это как раз буква «M». Если вы четко определились с остальными: целью (S), инструментами (A), оптимальным способом достижения ® и сроками (T) то дать оценку, это как в поле чудес слово отгадать с одной закрытой буквой.