я о том, что bare репозиторий вроде как не воспринимает прямые команды
%mkdir temp
%cd temp
%git init --bare
Initialized empty Git repository in /www/github/data/temp/
%git status
fatal: This operation must be run in a work tree
Согласен, если проект хорошо продан, больше половины описанных рисков не возникнет в принципе. Но на деле в организации 20% проектов продаются хорошо, а на прибыль от них тянутся остальные 80%.
Да и по статистике в 70% провальные проектов, основная причина — это недофинансирование.
У нас так исторически сложилось в компании, думаю что из-за дословного перевода от project manager
В принципе может возникнуть сопоставление с ролью «руководитель пакетов проектов, куратор проектов». Надо будет подкорректировать текст.
Кстати, отличная идея и тенденция в последнее время совмещать корзину и процедуру заказа. Реализовывали совмещенную страницу корзина + заказ, изначально в проекте эти страницы были разделены. В итоге конверсия поднялась на несколько %. Кому интересно, смотрите в этом проекте.
По поводу персональных данных — есть риски из-за не проработанности законодательства.
Но если ваш сервис предоставляет услуги, скажем бинарной обработки данных — т.е. данные не предоставляются как БД (закон распространяется только на персональные данные в виде БД), а как поток бинарных данных, то эта проблема отпадает. Есть соглашение, не помню ссылки, но есть, которое исключает провайдеров, операторов почтовых сервисов, сервис Whois из под действия данного законодательства.
Почему же я путаю? Я реально понимаю что такое SaaS-модель распространения программного обеспечения и никак не привязываю ее только к сайтам и порталам и только к вебу.
Я как раз старался ответить на вопрос о массовой разработке софта по SaaS модели — это когда SaaS-сервисы будет делаться также массово как сейчас сайты или десктопные приложения.
И конкретно хотел сосредоточился на проблемах, которые ждут разработчиков — web-студии, в этом сегменте. Т.е. чтобы правильно оценили ожидающие их бизнес-риски.
Подход хороший если ресурсов достаточно, но если 5-й пункт срабатывает — борьба за ресурсы в условиях ограниченного бюджета, то работать приходится с теми людьми что доступны.
Тут надо придумать какой-то личностный мотиватор, чтобы воздействовал на профессиональную гордость.
Как-то так…
Есть еще реальный процесс разработки дизайна.
Как правило очень много времени тратится на общий прием концепта, рассматривается не один вариант, и тут до мелочей и проработки деталей руки уже не доходят так как начинают гореть сроки.
Поэтому после принятия концепта должен выделяться отдельный процесс на проработку мелочей, и всех описанных в статье деталей.
1. По поводу главной страницы, скорее да, согласен с вами, если вы продаете что-то «бутиковое» или у вас узкая ниша в которой ценится подача и обертка (например ювелирные изделия), тогда Вам нужно показать стиль и надежность. Это лицо магазина и решающий "+" когда нужен последний довод для покупки.
2. По поводу «персональных выборок» и «смотрят также» — согласен, имеет место быть, но важно наличие посещаемости и релевантного комьюнити.
Все правильно вы говорите. Сейчас постиндустриальное время, выводить товары на рынок гораздо сложнее чем их производить, они быстро устаревают. В цене продута/услуги массовая доля за маркетинг и продажи гораздо больше чем «материалы» и «производство». Это могут себе позволить только гиганты. Но и они перестраиваются после индустриальной эпохи, когда все производство только крупными партиями, маржа минимальна и доход делается на огромных оборотах.
Поэтому такая цена за маркетинг.
мысль на счет SaaS нам казалась очень правильной, пока не попробовали этот сегмент.
оказалось что это настолько разные сегменты, что требуют даже другого состава команды, другой квалификации специалистов и другую модель управления.
Но самые сложности — это саппорт и продажи.
Если интересны подробности — пишите в личку
В эту схему еще нужно добавить коэффициент риска k1<K2<k3
сам коэффициент при этом будет сильно расти и делает функцию иррациональной, а местами и неопределенной
прибыль = f(kn,[a,b, в, г])
Да, это расчет для Киева.
Согласен, можно работать в этом сегменте «как-то жить» компенсируя состоявшиеся риски за счет других проектов, овертаймами, работой в ноль.
Поскольку очень редко в какой компании размером от 5 до 30 человек поставлен проектный учет и никто не знает реальную себестоимость проекта.
+ scrum master
%mkdir temp
%cd temp
%git init --bare
Initialized empty Git repository in /www/github/data/temp/
%git status
fatal: This operation must be run in a work tree
Да и по статистике в 70% провальные проектов, основная причина — это недофинансирование.
В принципе может возникнуть сопоставление с ролью «руководитель пакетов проектов, куратор проектов». Надо будет подкорректировать текст.
Но если ваш сервис предоставляет услуги, скажем бинарной обработки данных — т.е. данные не предоставляются как БД (закон распространяется только на персональные данные в виде БД), а как поток бинарных данных, то эта проблема отпадает. Есть соглашение, не помню ссылки, но есть, которое исключает провайдеров, операторов почтовых сервисов, сервис Whois из под действия данного законодательства.
И конкретно хотел сосредоточился на проблемах, которые ждут разработчиков — web-студии, в этом сегменте. Т.е. чтобы правильно оценили ожидающие их бизнес-риски.
Тут надо придумать какой-то личностный мотиватор, чтобы воздействовал на профессиональную гордость.
Как-то так…
Как правило очень много времени тратится на общий прием концепта, рассматривается не один вариант, и тут до мелочей и проработки деталей руки уже не доходят так как начинают гореть сроки.
Поэтому после принятия концепта должен выделяться отдельный процесс на проработку мелочей, и всех описанных в статье деталей.
Разметку поправлю как только карма будет ноль
2. По поводу «персональных выборок» и «смотрят также» — согласен, имеет место быть, но важно наличие посещаемости и релевантного комьюнити.
Поэтому такая цена за маркетинг.
оказалось что это настолько разные сегменты, что требуют даже другого состава команды, другой квалификации специалистов и другую модель управления.
Но самые сложности — это саппорт и продажи.
Если интересны подробности — пишите в личку
сам коэффициент при этом будет сильно расти и делает функцию иррациональной, а местами и неопределенной
прибыль = f(kn,[a,b, в, г])
Согласен, можно работать в этом сегменте «как-то жить» компенсируя состоявшиеся риски за счет других проектов, овертаймами, работой в ноль.
Поскольку очень редко в какой компании размером от 5 до 30 человек поставлен проектный учет и никто не знает реальную себестоимость проекта.