«Сколько это будет стоить и когда вы закончите?»

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

Интересуют, конечно же, не просто варианты ответов, а как дальше развивается ситуация в вашей компании?

До обраного В обраному 0

Этот, естественный для любого нормального человека, вопрос — главный камень преткновения всего ИТ бизнеса! От ответа на него полностью зависит все на проекте.Наиболее популярные сегодня варианты:1) «Вы сможете сами управлять ценой и сроками! Мы предоставим вам команду специалистов, а вы будете ставить им задачи как захотите.» Расшифровка: заказчику продают джунов под видом синьоров, что они сделают и когда — проблема заказчика.2) «У нас гибкая методика разработки. Каждые 2 недели вы будете видеть рабочее решение и сможете вносить коррективы.» Расшифровка: все не будет сделано никогда — нам выгоднее что бы заказчик вечно платил за «почти готовый» проект и его переделки.3) «Вам нужно на вчера? Мы умеем делать чудеса!» (индус-стайл). Расшифровка: мы работает тяп-ляп и в продакшин. Найдем готовый пример, нагоним толпу студентов перекрасить за еду — готово. Все баги и переделки — только за дополнительную плату.4) «Так ли для вас критичны сроки? Ведь у вас большой рабочий проект, который важно поддерживать. Спешка может только навредить!». Расшифровка: красивые похороны «мертвой лошади», когда проект уже прогнил, но продолжает служить средством «оприходования средств» в бюрократическом энтерпрайзе. На таком проекте заказчик и команда годами «красят траву» и деградируют — но денежки капают.5) «У вас компания из топ-фортун, хорошие юристы и контракт в котором прописаны сроки и пеня? Но мы компания мирового уровня — мы принимаем вызов!». Расшифровка: заказчик — не лох, бабла на нем не наварить, но бренд очень известный, для имиджа нужно, — поэтому придется работать по-честному. Собираем синьоров с других проектов, создаем «команду мечты», кормим их пиццей, поим пивом, разрешаем им делать как хотят — только бы уложились в сроки.Вывод: ИТ-галеры всегда хотят получать деньги не отвечая за результат проекта. Поэтому от ответа на этот вопрос постараются уходить любым способом. И только серьезный заказчик может «прогнуть» на подписание контракта, по-которому придется работать на-совесть. Это единственный тип проектов где настоящие профи еще бывают нужны ИТ-галерам. Все остальное — это не инженерия, а шоу-бизнес с танцующими для заказчика хипстерами.

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

В этом случае я задаю уточняющие вопросы до тех пор, пока заказчик не поймёт, что он не знает чего хочет и согласится на почасовку

На проектах, беру исключительно за отработанные часы. И контракты подписываю не сдельные, а повременные.

Если выдаёшь результат — клиенты остаются довольны.

Не знаю, насколько далека тема, но если предположить, что технология знакома, просто похожих проектов на ней не подымали. Тогда декомпозиция задачи на ряд мелких задач, разбиваем проект на этапы, каждый из которых оцениваем отдельно по срокам и цене. Здесь же написание подробного ТЗ на каждый этап и утверждение с заказчиком всех требований и Definition-of-Done. Долго, нужно, неприятно, но необходимо

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

(минутка рекламы) Я на основе книги «Сколько стоит программный продукт» делала доклад в котором много ответов на ваш вопрос www.youtube.com/watch?v=HOHEeEXMKcUПосмотрите, если поможет, не зря делала. По-быстрому -> пролистайте слайды bit.ly/2DmsVXD Если есть больше времени: очень рекомендую эту книжку, если вам нужно по работе регулярно давать эстимейты.

Ниже уже упомянули конус неопределенности: чем больше неопределенности тем менее точный можно дать эстимейт. Еще и вы и заказчик должны понимать что сроки зависят от многих других параметров — гуглите по слову COCOMO 2 bit.ly/2EVCVra — там список параметров влияющих на сроки и эстимейты.

Характеристики продуктаТребуемая надежность ПОРазмер БД приложенияСложность продуктаХарактеристики аппаратного обеспеченияОграничения быстродействия при выполнении программыОграничения памятиНеустойчивость окружения виртуальной машиныТребуемое время восстановленияХарактеристики персоналаАналитические способностиСпособности к разработке ПООпыт разработкиОпыт использования виртуальных машинОпыт разработки на языках программированияХарактеристики проектаИспользование инструментария разработки ПОПрименение методов разработки ПОТребования соблюдения графика разработки

Быстро и более-менее точно дать эстимейт вы можете только если недавно делали подобный проект.

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

Сам всем рекомендую, но на практике ещё не видел заказчика, который бы согласился с разбросом, например, −75% +100%.

На этапе «вот у меня есть идея, прикиньте примерно» −75% — 100% — это недостижимый показатель. Реалистично −400% — 400%.

Важно другое: что бы там себе заказчик не думал — эта неопределенность никуда не денется. И десятилетия разработки софта не приносят особого облегчения — точная оценка заранее по-прежнему невозможна. Мир не сделается проще от того, что кто-то чего-то не понимает. Заказчик может не соглашаться с разбросом, но разброс от этого меньше не станет. Остается или убеждать заказчика, перекладывать риски или играть в рулетку, если больше ничего не остается.

Возможна. Просто стоит дорого и требует много времени, что во многих случаях не устраивает реалии бизнеса.

только за счет решения всех неопределенностей.по хотелкам, по технологиям, по процессам.тогда — да.

Оценивание по своей сути на 90% состоит из прояснения неопределенностей :)

отлично. согласен.теперь мы приходим к тому, с чего началась тема: клиент вместо процесса прояснения неопределенностей ожидает получить четкий эстимейт и цену.

Значит заказчик считает что «все уже ясно, скажите сколько это будет стоить». А исполнитель(топикстартер) честно признает, что он вообще ничего не понимает в бизнес домене заказчика, не понимает какие вопросы надо задавать, но проект оценить хочет.

Как узнаешь что где раздают — займи мне очередь

Ну, возможна конечно, в момент, когда проект закончен — известна его точная оценка.А заранее — невозможна.

Я немного позанудствую и отмечу, что наш мир имеет вероятностую природу, а раз так, то точные априорные оценки в принципе невозможны. Котэ шредингера гарантирует. Но, тем не менее, возможно достаточно точно оценивать программные проекты. Fixed price проекты делаются, некоторые даже успешно.

сорри, подколоть вас не хочу, но получилось забавно :)

как и было задумано, пасиба что заметили :)

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

Тут как раз топик о случае, когда нет человека (лида или аналитика), который ранее делал что-то подобное.

Нужен человек который умеет (1) хорошо выяснить и детализировать требования.(2) на основе требований — предоставленных в виде документации — поставить эстимейты. Первое — это аналитик. Второе — хороший технарь. Не обязательно он должен «ранее делать что-то подобное» — в смысле не обязательно чтобы он уже делал подобный проект.

А вот нет. Аналитик должен иметь domain knowledge, а технарь — relevant experience. А когда таких людей нет — происходит упс. Ну вот прийдут к Вам как к технарю и спросят, сколько надо времени чтобы сделать, например, сенсор движения на батарейке с передачей данных по LoRa на кастомном чипе по Вашей схемотехнике. И что Вы как технарь ответите?

Так если вы не делали даже _приблизительно_ подобного (работаете совершенно по другому профилю), то сразу нужно отказываться от проекта. А не пытаться эстимейтить неизвестное.

А если никто не делал в этой стране — тоже отказываться?

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

Тогда это уже не будет эстимейт)

Правильно, поэтому само выражение «точный эстимейт» — оксюморон.

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

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

Да , все так, но сначала заказчик проходит через все эти фазы. :)

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

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

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

Оооо, эти «когда будет сделано?!» Напомнило свежее, из первых рук:

Корпорация из одного человека (ну как человека — индуса), может постить свои вакансии на любых ресурсах. Эстимейты подтверждает только те, где учтено время только чистое время на печатанье готового решения. Ведь «ю олреди хэв экспертиз!»

То есть анализ документации, мало-мальский rnd как в данном случае сделать лучше, — нет, не слышал!Так на лошках и строит свой «бизнес».

а не надо брать проект в далекой теме а потом выкручиватся.

согласен. Просто я часто работаю с фрилансерами-субподрядчиками. Многие не просто врут — даже требований к проекту не читают подавая заявку. По принципу главное завалить а потом запинаем. У меня конечно такие номера не проходят но если заказчик далек от ИТ и не ориентируется то дела заканчиваются плачевно.

Ну я не говорю что там именно разводилы. Просто безответственное отношение.

Сейчас рынок заказчика. Или делай что скажут и молись чтобы заплатили или сиди голодным.

Те 10 процентов приличных, когда беруться сделать двигатель с КПД 800% все еще приличные?

Не в такой степени. Процентов всегда будут зоной неопределенности даже в своей областьи. На можно принимать риски. Но не на

Допустим вы делаете ремонт. Нашли чувака, чтобы он сделал вам электрику. Задали вполне логичные вопросы про сроки и цены, еще спросили про то какую проводку лучше закупать. Мужик ничего толком не ответил, но вечером стал обзванивать всех своих знакомых с вопросом «я всю жисть сантехнику делал, но вот есть заказ проложить электрику, подскажите с чего начинать и какой провод покупать». Что то мне подсказывает, что если мужик сообразительный, выучится быстро, и советы ему дельные дадут, и он еще цену выставит в 3 раза ниже конкурентов, то вы врядле будете довольны результатом.

Раз у тебя получается находить заказчиков и обьяснять им что «гугл за 3 дня» не делается, то у тебя есть требуемая квалификация делать R&D проекты. У ТС вообще непонятно, R&D или просто незнакомый бизнес домен/технологии.

Программирование немного отличается. У электрика можно спросить за образование и опыт и нанимать того, который по нему электрик (ну могут конечно соврать). А если электрик — там всё довольно типовое. А данная ситуация о другом. Вот знаешь ты допустим весь стек для написания веб-приложения, к тебе приходит клиент, и ему нужно приложение для ведения например документации в какой-то сфере. И половина задания в терминах этой сферы. И тут три варианта — или сказать «такое не делаю» и заказчика перехватит не такой скромный (и возможно неквалифицированный) исполнитель, или сказать «всё сделаю за месяц» (и соврать) или сказать честно что такого не делал и предложить работать по почасовому контракту. Но проблема в том, что если идти всегда по первому пути — можно и голодным остаться, по второму — не все могут и хотят потом изворачиваться, а на третий бывает сложно уговорить заказчика. Впрочем я всегда за третий, а не хочет — пусть ищет того кто соврёт и будет потом кормить завтраками. В общем-то суть проблемы в том, что создание продукта не ограничивается знанием только программирования (а вот прокладка электрики это в основном знание электрики, мне сложно придумать там смежные области).

Ничем не отличается.

Программистов тоже собеседуют, спрашивают про опыт и(реже) образование.

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

На рынке квартирного ремонта тоже валом бригад, работающих «почасово». И с ними ровно тежи преимущества(дешевле) и тежи недостатки(скоуп растягивают, баклуши бьют) что и у программистов. :)

> Ничем не отличается.Ага, сроки вскопки огорода и создания вакцини от спида просчитываются одинаково линейно

Ну всетаки с R&D немножко другая ситуация, результат исследования неизвестен заранее, соотвественно количество требуемых исследований тоже неизвестно. Но если учесть это, то сроки проведения конкретно взятого исследования с по созданию вакцины для спида просчитывается также линейно как и вскапывание огорода. Просто нужен более грамотный менеджер. :)

Нет, более новомодная. От вакцин от сткарости много древнекитайских императоров погибло, говорят. Про спид тогда еще не знали.

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

Этот, естественный для любого нормального человека, вопрос — главный камень преткновения всего ИТ бизнеса! От ответа на него полностью зависит все на проекте.Наиболее популярные сегодня варианты:1) «Вы сможете сами управлять ценой и сроками! Мы предоставим вам команду специалистов, а вы будете ставить им задачи как захотите.» Расшифровка: заказчику продают джунов под видом синьоров, что они сделают и когда — проблема заказчика.2) «У нас гибкая методика разработки. Каждые 2 недели вы будете видеть рабочее решение и сможете вносить коррективы.» Расшифровка: все не будет сделано никогда — нам выгоднее что бы заказчик вечно платил за «почти готовый» проект и его переделки.3) «Вам нужно на вчера? Мы умеем делать чудеса!» (индус-стайл). Расшифровка: мы работает тяп-ляп и в продакшин. Найдем готовый пример, нагоним толпу студентов перекрасить за еду — готово. Все баги и переделки — только за дополнительную плату.4) «Так ли для вас критичны сроки? Ведь у вас большой рабочий проект, который важно поддерживать. Спешка может только навредить!». Расшифровка: красивые похороны «мертвой лошади», когда проект уже прогнил, но продолжает служить средством «оприходования средств» в бюрократическом энтерпрайзе. На таком проекте заказчик и команда годами «красят траву» и деградируют — но денежки капают.5) «У вас компания из топ-фортун, хорошие юристы и контракт в котором прописаны сроки и пеня? Но мы компания мирового уровня — мы принимаем вызов!». Расшифровка: заказчик — не лох, бабла на нем не наварить, но бренд очень известный, для имиджа нужно, — поэтому придется работать по-честному. Собираем синьоров с других проектов, создаем «команду мечты», кормим их пиццей, поим пивом, разрешаем им делать как хотят — только бы уложились в сроки.Вывод: ИТ-галеры всегда хотят получать деньги не отвечая за результат проекта. Поэтому от ответа на этот вопрос постараются уходить любым способом. И только серьезный заказчик может «прогнуть» на подписание контракта, по-которому придется работать на-совесть. Это единственный тип проектов где настоящие профи еще бывают нужны ИТ-галерам. Все остальное — это не инженерия, а шоу-бизнес с танцующими для заказчика хипстерами.

Не соглашусь. Есть 2 основные системы оплаты, которые прописывают в IT контрактах: T&M и Fixed Price. Отмазки хороши по T&M. По Fixed Price расклад другой: заказчик платит фиксированную сумму и оговаривает время и скоуп работ, которые должны быть выполнены. Команда и синьорити — проблемы исполнителя. Хочешь — нанимай 1 студента, а остальное бабло положи себе в карман. Хочешь — найми дрим тим и останься с пустыми карманами. Главное, чтобы скоуп был выполнен вовремя и с надлежащим качеством (тоже прописывается в контракте), иначе пеня.