Category: it

Фото

Это исторически заглавный пост

(Показывает на глобусе из каких стран и городов посетители моего блога в текущий момент.
Глобус можно крутить в разные стороны, приближать.)

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


Про изменение френд-политики.

Моя почта:
videoelektronic
(собака)yandex.ru


Счетчик PR-CY.Rank

Счетчик PR-CY.Rank

Счетчик PR-CY.Rank
promo videoelektronic may 5, 2018 21:48 2
Buy for 40 tokens
А скачать (абсолютно бесплатно!) можно тут: https://play.google.com/store/apps/details?id=com.skvgames.GemStripes
Фото

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

Итак, примерно с июля сего года я решил, что текущего способа получения заказов через устоявшиеся деловые связи не достаточно.
Да, у компаний нашей группы уже давно были сайты (некоторые знакомые даже говорят, что не плохие)
www.melz-elt.ru
www.remos-dubna.ru
www.arcaim-cnc.ru
www.opteh.ru

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

Что же было сделано для реального маркетинга через Интернет:



1) Сперва я своими силами, а потом и подуключив одного из наших работников, начали составлять базу данных потенциальных потребителей наших услуг. Составляли очень просто, перелапачивая различные поисковики, сайты-каталоги предприятий и сайты тематических выставок.
После нахождения нового потенциально интересного нам, как потребитель, предприятия, его сайт анализировался и оттуда вытаскивались все почтовые электронные адреса, телефоны, почтовые адреса. На основе информации из сайта определялась сфера деятельности предприятия и вытащенная информация помещалась в нашу базу данных по одному из десятка заранее определённых направлений деятельности.
2) Для каждого направления деятельности нашей базы данных была подготовлена своя презентация с упором на наиболее вероятные для этого направления деятельности наши компетенции.
3) В середине августа, когда в нашей базе данных было уже более 200 предприятий, были произведены первые рассылки рекламы. Недавно мы повторили эту рассылку, но уже имея в базе данных более 300 предприятий.
4) Параллельно мы занимались подъемом наших сайтов в поисковых системах. Пока внимание обратили на Яндекс и наиболее простые сайты, узко описывающие наиболее формализуемые виды нашей деятельности.
Мы воспользовались инструментом Яндекса https://webmaster.yandex.ru/sites/?hostnameFilter=
после чего в выдаче Яндекса, например, наш сайт www.arcaim-cnc.ru стал первым-вторым по запросу "производство высокоточных механических деталей" и в первой десятке по просто "производство механических деталей".
Возможно, что на повышение рейтинга посещаемости сайта так же сказалось то, что я достаточно сильно поспамил этим сайтом в группах ФБ, за что даже был забанен для активных действий на 5 дней недавно.
5) Кстати, по Фейсбуку. Я занялся привлечением там новых друзей, которых я ищу по нескольким профилям профессиональной деятельности: вакуумные технологии, высоковольные системы, обработка стекла, обработка металла. В основном, это получаются иностранные френды, которые активно отзываются на предложения взаимной дружбы. Но эта работа на перспективу. Пока не понятно, что она может дать практически.
Да, если интересно, то моя страничка в facebook: https://www.facebook.com/videoelektronic
Страница нашей группы компаний: https://www.facebook.com/LLC-MELZ-387019791432382/

Какие же мы получили результаты всей этой работы?
1) За прошедший месяц пришло 3 дополнительных заказа на металлобобработку от малых компаний.
2) Вчера поступил запрос на сотрудничества в сфере производства металлических детаталей для достаточно крупного московского НИИ, сходящего в одну из известных всем госкорпораций. Причём, это предприятие точно было в списке наших рассылок и его снабжение заинтересовал именно имеющийся у нас набор компетенций.
3) Являясь достаточно автономной от нас наша компания ООО "Оптех" за прошедший месяц смогла получить двух достаточно крупных для малого бизнеса в сфере разработки и производства электроники заказчиков.



Собственно, пока это всё у меня для вас по маркетингу.
Как я оцениваю результат работы? Пока, на мой взгляд, он неплохой, хотя и не вылился ещё в финансовые доходы.
Как говорит мой знакой из Голландии, я буду держать вас в курсе новой информации.


The Dungeon Again!, Hell

Блокчейн, криптовалюта: краткая суть простым языком (Запасная сеть)

Оригинал взят у vamoisej в Блокчейн, криптовалюта: краткая суть простым языком (Запасная сеть)
Блокчейн, криптовалюта: краткая суть простым языком (Запасная сеть)

Идут постоянные споры и баталии  про криптовалюты:  зло - не зло, что г..но - Bitcoin или Ethereum.  Но всё гораздо проще.  Пока спорим они  уже устарели, а в разработке такие системы, которые даже сейчас трудно представить, но через 3-5 лет будут обычным делом.  Главное - понимать в чём изначальная суть. Постарались простым языком описать именно  этот момент.

Collapse )
The Dungeon Again!, Hell

Виды контрактов в заказной разработке

Оригинал взят у dz в Виды контрактов в заказной разработке
Эта статья, скорее - лирическое отступление, хотя для общей картины она тоже важна.

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

Для начала, перечислим традиционные модели взаимодействия клиента и исполнителя: Контракт с фиксированной ценой - Fixed price (FP), Повременная оплата - Time and material (T&M), Аутстафф - Outstaff.

Контракт с фиксированной ценой

Предполагает ответственность исполнителя за достижение определённых целей - как правило, зафиксированных в контракте и приложениях. Наиболее стабильный способ фиксации целей в таком контракте - детальные требования (см. артефакт "требования" - будет описан позже). На стороне исполнителя выполняется полный цикл работ от снятия требований до полной готовности продукта.

Ремарка: документ "требования" часто также называют "техническое задание", ТЗ, что не вполне верно. По ГОСТу требования есть часть ТЗ. Впрочем, пожалуй - самая важная.

Требования могут быть сформированы на начало контракта во всех необходимых деталях, могут быть очерчены схематично или могут вообще отсутствовать.

В том (нечастом) случае, когда заказчик предоставляет к началу контракта абсолютно полные и детальные требования (то есть - требования такой детальности, к которой привык исполнитель), проект может быть оценен с высокой точностью на начало контракта.

Отмечу, что только исполнитель решает, полны ли и детальны ли предоставленные заказчиком постановочные документы. В целом, если требования неполны, не всегда обязательно настаивать на их доработке до блеска. Иногда неполнота постановки является хорошим аргументом для контрактации по T&M и выполнения работ по agile.

Если требования отсутствуют или неполны, применяются две схемы контрактации.

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

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

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

Один из типовых механизмов в такой схеме - разбиение всех сформированных требований на приоритеты, и отработка требований от наиболее важных до наименее важных по схеме "пока не кончатся деньги". Опять же, впрочем, разбиение требований на приоритеты необходимо при любом подходе.

Контракт T&M

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

Контракты T&M довольно вариативны. В пределе при работе по такому контракту исполнитель может вообще не нести ответственность за сроки и стоимость, тогда схема приближается вплотную к аутстаффу (см. ниже) и, к примеру. менеджер проекта находится на стороне клиента. В другой крайности контракт T&M представляет собой практически fixed price контракт, но с ослабленными требованиями к составу релизов, стоимости и срокам. В такой контракт хорошо вписывается agile подход в той или иной его инкарнации. Например, жёсткий план проекта может быть заменён на беклог с уточнением состава релизов по ходу проекта. Впрочем, по сути, ничто не мешает делать то же самое и в проекте с фиксированной ценой. Другое дело, что в fix price проекте любая замена в составе функциональности проекта должна проходить жёсткую процедуру запроса на изменение (ЗИ, CR), а в T&M проекте схема согласования такого изменения может быть куда более расслабленной (в частности, не включать в себя точный подсчёт изменения сроков и стоимости проекта).

Аутстафф

В этом варианте контракта подрядчик вообще отвечает только за профессионализм сотрудников, которые от него работают на проекте. За требования, архитектуру, проектное управление и качество результата отвечает заказчик. Тем не менее, на таких проектах подрядчик может принимать очень глубокое участие в проектировании, постановке и проектном управлении - важно, что все эти функции он исполняет исключительно в режиме исполнения решений заказчика. Диапазон схем и здесь достаточно велик. В самом слабом случае подрядчик просто поставляет в команду разработки несколько линейных специалистов. В самом мощном случае фактическая экспертиза, проектные решения и иногда даже продуктовая/бизнес экспертиза находится на стороне подрядчика, а заказчик включает в команду лишь менеджера проекта, считая, что в этом случае он контролирует проект лучше.

Стороны и ресурсы

Необходимо отметить, что при любой схеме проекта практически любые ресурсы проекта - те или иные сотрудники, код, библиотеки, подсистемы, сервера - могут поставляться любой стороной проекта. Есть вещи незыблемые - например, при fixed price контракте исполнитель вряд ли допустит, чтобы менеджер проекта был не с его стороны - это выглядит как самоубийство. В остальном - вы вольны проектировать любой состав команды. Несколько примеров:

Два менеджера проекта - и подрядчик, и заказчик выставляют своего PM-а. Это - очень типовой и реально полезный вариант. Даже если со стороны заказчика нет полноценного проджекта, как минимум постоянный ответственный сотрудник должен быть аллоцирован.

Два архитектора - опять же, архитектор со стороны заказчика хорошо знает ландшафт и возможности команды заказчика и будет крайне полезен при принятии решений.

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

Дизайнер или проектировщик интерфейсов - иногда подключается исключительно из желания заказчика сократить затраты, иногда реально полезен как носитель знания о принятых глобальных правилах оформления или единообразного user experience на разных системах заказчика.

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

Ценность разработчиков со стороны заказчика, как правило, невелика, хотя, опять же, бывают варианты.

Консалтинг и точка принятия решений

Постулат: Решение принимает тот, кто за него платит. То есть - заказчик.

Постулат: Вы всегда консультируете заказчика. Вас потому и наняли.

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

  • Умение управлять проектом и достичь результата в срок и деньги. (Вы продали проектное управление)

  • Умение проектировать программные решения такого типа. (Вы продали архитектуру и технические решения)

  • Умение работать с бизнес-кейзами такого типа. (Вы продали бизнес-консалтинг.)

В сознании заказчика присутствует какой-то образ вашей компании. И какая-то оценка вас как носителя знаний по этим трём направлениям.

Если вы не компания, которая внедрила десяток крупных проектов такого рода за последние пару лет, то вряд ли вас оценивают как бизнес-консультанта в этой тематике. При этом по факту, скорее всего, вы накопили достаточный опыт в более широком классе проектов и стремитесь поделиться им с заказчиком. Что, в силу вышесказанного, не находит в нём понимания. Он - профессионал в своей области, чему вы можете его научить?

В частности, конфликты такого рода возникают, когда ваш заказчик переводит бизнес из офлайна в онлайн. Он действительно хорошо знает сам бизнес, а вы действительно лучше него знаете специфику онлайн-решений. И видите, что клиент (при постановке бизнес-процессов, как правило) совершает дикую ошибку. И пытаетесь предотвратить. И - вас мягко, а иногда и жёстко, разворачивают со словами "Ты же программист? Иди, программируй. Не лезь в наши дела."

Повторю, вы рассматриваете проблему как смертельную, то есть - не верите в успешность проекта в случае, если ваше предложение будет проигнорировано.

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

Далее можно:

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

  • Провести цикл совещаний с неключевыми сотрудниками заказчика, убедить их (желательно, очень аргументированно), и потом снова выйти на ЛПР, уже широким фронтом.

  • Молча продолжить работу, имплементируя неправильное решение заказчика (Вы же предупредили? Три раза? Он не внял? Это его решение.), но работая на снижение своих рисков - не допуская дебиторки, более чётко относясь к формальной стороне проекта (документам, актам и пр.)

  • Заявить, что риск в силу принятого решения столь велик, что вы хотели бы сняться с проекта, или же получить твёрдые (желательно - в виде предоплаты за все оставшиеся работы) заверения заказчика, что он точно отвечает за этот риск сам.

Если такая ситуация (принятие заказчиком самоубийственного решения) случилась на проекте с заказчиком-стартапом - бегите.
Фото

Росистые вычисления, или всё в тумане... Для тех, у кого глючный Интернет.

Конечно, певрое, что я могу посоветовать в таком случае, это сменить провайдера.

Например, вы можете выбрать нашу компанию www.tmpk.net
Но, если вы хотите остаться вырным своему старому провайдеру и скорости 9600 бод, то тогда вам надо прочесть эту статью, что бы узнать о новых технологиях:

Независимые вычисления, совместимые с облачными, называются росистыми (прости, Хабр, но другого хорошего определения Dew Computing на русском языке мы не нашли). Основной принцип росистых вычислений в том, что они восполняют основной недостаток облачных вычислений — требование к стабильному

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

далее по ссылке: https://habrahabr.ru/company/cloud4y/blog/307058/


Фото

Государство хочет контролировать маршруты интернет-трафика в стране



Это нужно для обеспечения безопасности рунета, утверждают чиновники

Минкомсвязи разработало законопроект о государственном контроле над прохождением интернет-трафика на территории России, следует из пояснительной записки к документу (у «Ведомостей» есть ее копия). Это проект поправок в законы «О связи» и «Об информации, информационных технологиях и защите информации». Такой документ существует, подтвердил «Ведомостям» чиновник профильного ведомства. О нем знают и сотрудники нескольких крупных операторов связи и интернет-компаний. По словам двух собеседников «Ведомостей», документ реализует поручения президента Владимира Путина по итогам заседания Совета безопасности, состоявшегося осенью 2014 г. Совет обсуждал итоги учений по устойчивости российского интернета и вопросы его автономной работы: речь шла о минимизации рисков для рунета в случае его временного отключения от внешнего мира при чрезвычайных ситуациях.

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

Все это поможет органам государственной власти понять, как работает российский сегмент интернета, объяснил «Ведомостям» федеральный чиновник. Сейчас у государства такого понимания нет: из-за хаотического развития рунет очень сложно устроен. А нужно все это для того, чтобы государство могло защитить рунет от внешних атак, утверждает он.

Например, необходимость создания реестра IP-адресов (уникальных адресов компьютеров в сети) он объясняет так: сейчас все IP-адреса выдает операторам голландская компания RIPE NCC, операторы в автоматическом режиме постоянно обращаются к базе данных этой компании и на ее основе строят маршруты трафика, и если вдруг из реестра самой RIPE NCC пропадет информация о российских IP-адресах, то весь рунет «ляжет» минимум на сутки. Государство предлагает создать резервную копию реестра IP-адресов, которая будет автоматически проверять наличие российских адресов в базе. Эту услугу государство предложит операторам, но обязывать их пользоваться такой базой не будет

http://www.vedomosti.ru/politics/articles/2016/02/11/628508-gosudarstvo-hochet-kontrolirovat-rossiiskii-zarubezhnii-internet-trafik-strane