Рубрика «управление проектами» - 22

Потому что дерьмо случается.

Обычный российский хостинг в такой ситуации продаёт юрлицо в Грозный (это проще, чем банкротство) и скрывается в ночи, чтобы потом открыться под новым названием, но уже без долгов и репутации. Некоторые сразу не кладут яйца в одну корзину и имеют несколько юрлиц (это ещё позволяет продавать новым дешевле то, за что постоянные клиенты платят по обычному прайсу). Мы по ряду причин так делать не можем — главная часть нашей экономики это серверное железо, а серверное железо требует долгих контрактов. Про это я писал вот здесь. И ещё мы строим маркетинг на репутации, как это ни странно.

Управление репутацией хостинга: почему стало так важно рассказывать про процессы открыто - 1

Перенос дата-центра OVH SBG2 в облако, 55 % complete

Когда вы строите что-то на репутации, самый ценный ресурс — это вес вашего слова. Нужно это для того, чтобы люди понимали, что у вас происходит, и разбирались вообще, что происходит на рынке. А ещё это становится критически важным, если случается что-то плохое: нужен кто-то, кто может выйти и рассказать о неправомерных действиях кого-то, о том, что действительно за авария и в каком ЦОДе, о том, что с блокировками и так далее.

То есть блог на Хабре — это часть нашего антикризисного плана. И, как показала практика переноса ЦОДа в облако примерно 10-летней давности, это бывает очень актуально.

В общем, есть много причин управлять репутацией хостинга, если вы на рынке больше чем на пару лет. Я бы хотел немного рассказать, что именно мы делаем для этого. Потому что на нашем рынке управление репутацией — это работа с негативом. Читать полностью »

Опросы проводятся ежедневно по всему миру. Хорошо продуманные дают полезный фидбек от аудитории. Плохие — пустую трату времени как для клиентов, так и для менеджера.

Да, людям не нравится проходить скучные опросы. А кому это ок? И поэтому одинаково отвечают на каждый вопрос, чтобы поскорее закончить, а часто, и вовсе не доходят до конца.
Читать полностью »

Что творится в хостинг-индустрии глобально в этом-прошлом годах и чего сейчас ждать - 1


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

Коротко:

  • Минкомсвязи хочет приземлить в РФ все зарубежные сервисы с выручкой.
  • IPv4 кончается, но, кажется, нам плевать.
  • Дефицит полупроводников вызывает полуповышение цен.
  • MS закручивает гайки ещё дальше.
  • Импортозамещающий «Байкал» наносит ответный удар.
  • Идут блокировки VPN по сценарию, стремящемуся к китайскому.
  • Удалёнка поменяла потребление VDS.
  • И Антимонопольная служба атакует крупнейшие ИТ-компании (хоть одна хорошая новость для пользователя).

Почти всё из этого вызывает увеличение издержек, и заплатите за них, конечно же, в конце концов именно вы. Потому что так работает экономика. Читать полностью »

Почему цена на хостинг не меняется каждый день из-за скачков курсов валют - 1

То есть каждый месяц будет значимое изменение цены на поставляемое серверное железо и цены на услуги ЦОДов в других странах. Например, в Англии в Лондоне или в Нидерландах в Амстердаме. Тем не менее мы удерживаем одинаковые цены постоянно и очень-очень редко их переиндексируем. Если быть более точными, то мы два раза за свою историю повышали цены на 10 %, предупреждали об этом за два месяца и предлагали дополнительные скидки для долгого продления по старым ценам.

Первое железо мы начали покупать в 2014 году ещё для другого проекта и уже тогда столкнулись с очень резкими скачками цен из-за изменения курсов валют. То, что тогда стоило 400 тысяч рублей, сегодня по усреднённому уровню «потребительской корзины», то есть аналогичных хостинг-услуг в 2021 году, стоит уже примерно 1,5 миллиона рублей. И это не только и не столько инфляция, сколько доллар, который стоит уже не 30 и не 32 рубля.

А ещё время от времени производители софта преподносят сюрпризы вроде: «У нас чуть обновилось соглашение», а открываешь — там изменение цены на лицензии вдвое.

Задачу оптимальной экономики можно решать тремя путями:

  1. Постоянно перекладывать колебания курса на клиента.
  2. Прогнозировать некий разброс, скажем, 10 % роста в год.
  3. Покупать какой-то актив, который изменяется обратно пропорционально курсу доллара и евро.

Сейчас расскажу, как это устроено у нас. Читать полностью »

Почему у нас такое жёсткое лицензионное соглашение - 1

Первый конфликт — в том, чтобы дать клиентам хостинга максимально хорошие условия, с одной стороны, но при этом помнить, что любая виртуальная среда — это коммунальная квартира. И сервер у нескольких виртуальных машин общий, поэтому нужны правила общежития. Решение такое: если гадит кто-то один — нужно его выселять, чтобы не было плохо остальным. Дальше нужно определить в соглашении, что именно хорошо, а что — плохо.

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

Третий конфликт — лицензии MS, про что я уже писал в прошлый раз, когда касался пиратов. MS хочет иметь доступ к виртуальной машине со своим софтом 24/7, а в российской юрисдикции ВМ начиная от уровня гостевой ОС полностью закрыта для хостера. В итоге появляется костыль с аудитами по заявлениям о пиратстве — его мы разберём ещё раз. Читать полностью »

Чем разработчик от кодера отличается - 1

Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.

«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.

Читать полностью »

Чему поучиться у братьев Райт — как резать фичи и запускать MVP - 1

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

Про образование не шучу — Уилбер и Орвилл Райт даже школу не закончили.
В чём прикол братьев Райт и чем их история поучительна для менеджеров проектов?
Может, они были богатые сумасброды? Да нет, всего лишь средней руки предприниматели — владели магазином велосипедов и веломастерской.

В общем, хотите поскорее запустить работающий прототип — урезайте хотелки. А теперь следите за руками:
Читать полностью »

Разработка (dev) и data science в enterprise — битва за ресурсы или эффективное сотрудничество? - 1


В подавляющем большинстве случаев, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.

Материал является продолжением серии предыдущих публикаций.
Читать полностью »

Делу время, потехе час! Тезисы «мифического человеко-месяца» Фредерика Брукса, в пословицах и поговорках - 1


Время — судья

Книга “мифический человеко-месяц”, заслуживает того, чтобы её читали и перечитывали, издавали и переиздавали. В 2025 году, а он не за горами, будет 50 лет первому изданию. Т.е. проверка временем пройдена. В 1995 году вышло юбилейное издание (ждём юбилейного издания 2К25), в предисловии к которому, автор, помимо прочего, сообщает:

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

Кто празднику рад, тот накануне пьян

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

В споре рождается истина

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

А заодно расслабиться, и повеселиться. Не воспринимайте написанное слишком буквально — без смешного нельзя понять серьёзное. Читать полностью »

Привет! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами. 

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js