Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Интересно кто как отвечает на эти вопросы заказчика?

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

точная оценка заранее по-прежнему невозможна

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

Возможна

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

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

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

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

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

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

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

Fixed price проекты делаются, некоторые даже успешно.
некоторые даже успешно
некоторые

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

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

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

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

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

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

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

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

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

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

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

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

Самый правильный вариант

Для кого?

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

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

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

А вот показать и доказать свою экспертизу очень непросто.

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

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

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

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

Frederico Carrasco, Graypes
www.crunchbase.com/person/federico-carrasco
www.linkedin.com/in/carrascofederico

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

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

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

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

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

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

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

Не в такой степени. Процентов 10-15 всегда будут зоной неопределенности даже в своей областьи. На 16-40 — можно принимать риски. Но не на 50-90.

Допустим вы делаете ремонт. Нашли чувака, чтобы он сделал вам электрику. Задали вполне логичные вопросы про сроки и цены, еще спросили про то какую проводку лучше закупать. Мужик ничего толком не ответил, но вечером стал обзванивать всех своих знакомых с вопросом «я всю жисть сантехнику делал, но вот есть заказ проложить электрику, подскажите с чего начинать и какой провод покупать»...
Что то мне подсказывает, что если мужик сообразительный, выучится быстро, и советы ему дельные дадут, и он еще цену выставит в 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 студента, а остальное бабло положи себе в карман. Хочешь — найми дрим тим и останься с пустыми карманами. Главное, чтобы скоуп был выполнен вовремя и с надлежащим качеством (тоже прописывается в контракте), иначе пеня.

Бить на этапы.
1. Проэктно — сметный.
2. Пруф-оф-концепт (показать решения ключевых задач проекта в отрыве от общего контекста).
3. Дальше поэтапно, согласно (1)

А что если второй этап это 50%-90% работы?
Область работы новая, опыта ни у кого нет, поэтому после начала реальной работы проект, нарисованный на первом этапе, можно сразу выбросить в мусор вместе со сроками работ, так как после столкновения с реальность это всё будет представлять собой не более чем милую сказку о розовых пони.

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

Если не хочется светить проэкт — можно в личке более предметно обсудить.

Вы как-то сами себе противоречите. То пишите что минимальный функционал это 50-90%, то теперь что второй этап.
Модное нынче слово R&D (Research and Development) — это как раз об этом.
Если вы делаете что-то новое, для чего нету примеров — то это Research, и заказчик должен это понимать. Результат исследования — это не финальный продукт, а в лучшем случае — прототип, в худшем — ответ что сделать так не получилось. Но заказчик платит за проведение исследования, а не за его результат! Сроки исследования то же можно задать: исследуем 3 месяца, после этого анализируем что получилось.
А вот Development — это разработка чего-то конкретного. А значит у него есть аналоги и конкуренты. И тут ситуация другая: заказчик всегда может оценить сколько вообще стоят подобные проекты и за сколько их делают. Если у вас нет опыта в таких проектах — это ваши проблемы и совсем не значит что заказчик должен ждать дольше или платить больше. Он вполне может найти тех, у кого опыт есть.
Именно поэтому сейлзы часто договариваются о сроках, не спрашивая разработчиков. Просто потому, что знают, что конкуренты делают такие проекты за Х месяцев. Загадать больше — потерять клиента. Ну а отсутствие опыта или синьоров — это проблема менеджмента, который всегда хочет сэкономить. И проблемы эти, при желании, то же решаются — поиском опытных людей в команду, организацией обучения, привлечением экспертов (иногда — сторонних) и т.д. Толковый менеджер будет решать, бестолковый наберет команду джунов и заставит овертаймить в надежде что они «родят за месяц».

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

Договориться о разработке прототипа и подробного технического задания как отдельной предварительной работе. Реализовать внешнюю сторону (в основном визуальную) на чём-то предельно банальном и знакомом. Честно выдать все результаты, включая отчёт, код, шаблоны и тикеты (где надо, навесить лицензионные барьеры).
По завершению этой части вы получили свою честную копейку, а заказчик имеет о чём подумать. Если работа тут прервётся — не страшно, значит, вы бы всё равно не поладили.

Я тут dou.ua/...​rums/topic/22841/#1265723 написал пару примеров в которых реализация работающего прототипа фактически является выполнением большей и наиболее рискованной части работы. В обоих примерах визуальная часть тривиальна и не играет роли.

Да, я видел. И зачем вы это ещё раз комментируете? Такие работы достаточно редкие, скорее всего ТС не попадутся. Если попадутся, то опознать их специфику легко. Тогда и подходы другие.

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

Прежде всего договоритесь реализовать минимум функционала, необходимого для работы проекта. Оцените примерно на глазок сколько это займёт времени. Добавьте процентов 30% времени на форсмажорные обстоятельства. Умножьте это время на среднюю величину зарплаты в данной теме — и будет стоимость.

Допустим что минимум функциональности, необходимый для работы программы, которую можно показать заказчику это от 50% до 90% всей работы. Например заказчик хочет реализацию видео-чата на новом протоколе передачи данных с помощью нового чипа заказчика. Чтобы передать первый байт надо сделать практически всю работу. Дальше уже можно прикрутить к этой системе любой из готовых видео-чатов. Или заказчик хочет новую видео-игру для которой нужно сделать свой собственный движок на уникальных принципах (иначе зачем огород городить) и инструменты разработки. Чтобы нарисовать на экране первый треугольник нужно проделать как минимум половину всей работы. Как вы оцениваете «на глазок» разработку подобных сложных штук, которые ещё никто никогда не делал и специалистов по которым на рынке нет, и у вас нет никакого представления сколько потребуется времени на обучение и эксперименты у тех работников, которых вы сможете найти на этот проект пока они не получат достаточный опыт чтобы предсказывать сложность задач которые им нужно будет решать?

Это Ваш случай?

А так, сделайте х10 к предполагаемому, раз это на столько уникальная и инновационная задача )

Конечно мой иначе зачем бы я спрашивал. А х10 от какого числа? Как именно Вы это число предположили?

По видеочатам есть специалисты в Ринге — думаю, там уже сейчас многие не особо довольны. По движкам — тоже можно в геймдеве поискать.
Например, с видеочатом можно разбить на следующие этапы:
1) поднять видео по SIP и отладить ввод/вывод
2) поднять протокол заказчика с передачей произвольных данных и отладить проход через NAT, восстановление ключевых кадров и jitter
3) поднять произвольный софт (Linux/uC-OS2) на чипе заказчика
Это все могут делать в параллель разные люди, а потом — свести в кучу. И каждая из этих задач уже не столь экзотична. Divide & Conquer, либо пример не настолько плох, как реальная жизнь.

Я, конечно, не по всем перечисленным статьям специалист, только по SIP. Могу вам заметить, что команда linphone уже лет 5 пытается из проекта убрать баги по вашим пунктам 1,2 и пока не преуспела. То, что у вас написано в 1,2 вполне можно оценивать для большинства протоколов в 10-20 человеко-лет. А большинство «специалистов по видеочатам» это чуваки, которые по полгода поработали с webrtc и считают, что они профи. Реальных специалистов единицы.

Вот видите, на рынке вполне себе доступен человек, который может дать оценку 2/3 объема задачи. А Вы говорили — нету)
P.S. для аудио рекомендую pjsip, видео на нем не поднимал — там надо лезть в билд систему.

Не могу я дать оценку. Я могу дать только ПОРЯДОК оценки. Тоесть сказать, что это десятки человеко-лет. Я pjsip пытался использовать четыре раза, последний в августе этого года. Короче, он тупо подвисает в какомто внутреннем deadlock при определенной сумарной дневной активности(порядка 100к в день). Что ставит крест на его использованнии в более-менее нагруженных системах. Что самое паршивое, повисает непредсказуемо и вообще без всякой диагностики.

100k чего? звонков в день?
Вообще у него хороший саппорт. И повисание можно отдебажить, если воспроизводится. Или вочдог поставить.
Мы проблем от него не огребали уже пару лет, правда, нагрузочного тестирования не делали. Стабильность и легкость использования хорошие.

в среднем 100к звонков с запуска сервиса. Не воспроизводится. Поскольку на синтетических(правильных) тестах типа sipp его нет, а на практических он не выдает уже никакую информацию после подвисания.
На малых нагрузках, похоже, шанс получания эффекта ниже. В общем нефига не получается его отдебажить.

впилить вочдог. будет перезапуск вместо повисания. креш на 1 звонок из 100000 это 0.0001% отказа — мегакруто для любой не life-critical системы.

Ну так надо для начала определить, что именно у вас повис канал. А в связи с природой sip протокола это невозможно(ну не шлет оно пакеты внутри разговора и rtp вообще идет вне pjsip). Тоесть о том, что канал завис вы узнаете, попробывав новый звонок втулить. Причем как узнаете. Звонок пойдет. Просто будет неограниченно процесситься. Короче, вочдог в данном случае равносилен sipproxy перед стеком, проще перейти на работающий стек, а на этот забить. Собственно, потому этот баг никто и не нашел пока.
А 2-5 минут(пока система мониторинга гарантированно поймет, что новые звонки не процессяться) отсутвия реакции от системы телефонии очень выбешивают клиентов и техподдержку.

У pjsip есть audio device через который как раз голос и идет. И он дергается по слипу 20 мс, кажется. Если пропадает голос — можно туда пилить вочдог.
Если виснет собственно SIP — ставите хуки на приеме запроса на исходящий звонок и на отсылке SIP сообщения. Если запрос принят, а сообщение не ушло — висим, надо убиться. Еще, если там реальный дедлок, то потоки отвечать не будут — можно их пинговать какими-то мелкими вызовами раз в пару секунд.

Запрос принят а сообщение не ушло — штатная ситация для многих вариантов диалплана. Мелкие вызовы при приличной нагрузке достаточно часто выполняются секундами(5,10,15 секунд). Сразу убивать нельзя(это еще хуже чем повисание). Тоесть надо получить 3 подтверждения минимум. Отсюда и получается время детекта 2-5 минут.
RTP идет вообще через другой канал. Оно работает без нареканий.

Запрос принят а сообщение не ушло — штатная ситация для многих вариантов диалплана.

Не понял. Вызов pjsua_call_make_call() должен достаточно быстро вернуть результат и выплюнуть SIP пакет в сеть, если поднят сетевой интерфейс и если результат == PJ_SUCCESS.

Мелкие вызовы при приличной нагрузке достаточно часто выполняются секундами(5,10,15 секунд).

Нет, до 15 секунд выполняются только если лежит сетевой интерфейс, тогда pjsip влетает где-то в таймаут операционной системы при определении IP адреса. Иначе — все работает мгновенно, даже на роутере. Или у вас проц перегружен — тогда надо апгрейдиться.

Сразу убивать нельзя(это еще хуже чем повисание).

По UX повисание хуже, чем перезагрузка программы.

Фактически будет не 1 звонок, а CPS*5 минут(под тысячи в нагруженной системе). Мне тут клиент за 13 записей из полумиллиона, которые расходилися с контрольной системой мониторинга выносил мозг неделю.

Это у вас сколько пользователей висит на одном SIP клиенте?

А 2-5 минут(пока система мониторинга гарантированно поймет, что новые звонки не процессяться) отсутвия реакции от системы телефонии

Если стоит вочдог, то будет не 2-5 минут, а 5 секунд, и рестарт системы. Для этого вочдоги и существуют.
И можно снять стеки всех потоков, послав на них сигнал по вочдогу.

Я работаю с серверной частью. Пользователей то может и 1 быть, но потоки достигают 80-100CPS. Ну хз. Я не вижу как можно организовать вочдог на 5 секунд, если процессинг звонка в норме секунды. И бывают вполне реальные ситуации, когда в канале нет смены событий минутами(вечером). Еще раз, rtp поток не повисает, эта часть работает без нареканий.

А вы пытались поюзать pjsip как сервер?
Вочдог либо влепливается в основной цикл каждого потока, либо прокидывает собственное сообщение через всю систему и ловит его на выходе (например, отсылка и получение INFO с кастомным заголовком). Если в течении 5 сек приложение не дернуло вочдог, его убивают и рестартуют.
А что, linphone совсем стабилен?

У меня asterisk.org обычно. Там канал поверх pjsip. Нет, linphone вообще в ноль нестабилен. Он иногда по 100 ответов на сообщение шлет. chan_sip стабилен, но типа pjsip быстрее. Потому я его пробую с интервалом гдето в год(когда клиент просит явно его поставить), пока нет удачных установок.

По-идее надо из UA дергать pjsua_call_send_request(call_id, «INFO», «TEST») раз в 2 сек для случайного звонка; ловить в udp_send_msg(), сверять пакет с тестовым, если совпал — игнорить и дернуть вочдог.

Кстати, в Ринге говорили про FreeSwitch для видеозвонков. Как он по сравнению с Астериском?

Freeswitch быстрее, имеет более чистую архитектуру, имеет более сложные конфиги(xml). Но гараздо меньше пользователей, гараздо дольше находятся(и фиксятся) баги, гараздо сложнее найти техподдержку. В реальных задачах разница в производительности не стоит перехода, поскольку если она важна, то вам надо смотреть уже в сторону kamailio/opensips.

Ринге — думаю, там уже сейчас многие не особо довольны

А что там не так? Вроде же модные пацаны на взлете?

Там, вроде, менеджмент из Самсунга. Ну и они подобрали тех, кого остальные двое не хотели. Короче, поглядим. И опенспейс злой.

Там, вроде, менеджмент из Самсунга.

Вот оно как :)

Ну и они подобрали тех, кого остальные двое не хотели.

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

Підписатись на коментарі