Pull to refresh
69
0
IT-диктатор @sse

Пользователь

Send message

Точная цитата иная: добавление сотрудников к запаздывающему проекту заставит его запаздывать еще больше.

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

Рекомендую прочитать вот это https://fedorovpishet.ru/zettel-number/ и вот это https://fedorovpishet.ru/zettel-feature/ И соседние статьи автора про подробности метода, которые упускают при очередном копи-врайтинге.

Квадратный корень это быстрый приблизительный способ прикинуть порядок потребных ресурсов - скажем, человеко-часов. Пример: скажем, у вас есть условная оценка проекта от аналитика в 2 человеко-года или 24 человеко-месяца - это (берем корень) 5 человек * 5 месяцев. Пример очень игрушечный, но суть понятна, надеюсь

"Работает не трогай" доведен до высшего уровня, кое-где ходят трамваи с деревянными полами 30х годов. Можно и более современный пример увидеть: типично, японская компания выпускает первую версию автомобиля, затем по форумам, колл-центрами и прочим местам с обсуждениями ходят специальные люди и собирают отзывы на проблемные места, на которые жалуются, и в следующей ревизии модели автомобиля скрупулезно по списку каждая из этих проблем будет исправлена. Не фанат, но есть чему поучиться.

"Можно писать на любом языке" и "2-pizza team" это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:

1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.

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

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

Все, кроме этих двух причин на самом деле ни зачем не надо. А, еще маленькое замечание: проще нанимать людей, потому что "у нас такие же крутые технологии, как в Гугле (так что мы будем платить поменьше)".

У маленькой компании есть только одно преимущество -- она может стать большой компанией. По всем остальным параметрам человеку "с улицы" там будет хуже, как правило, чем в крупной

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

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

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

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

Во-первых, это ВАШЕ утверждение, что для непрямолинейного и неравноускоренного движения должны быть иные формулы. Формулировка Эйнштейна на парадокс близнецов таких ограничений на скорость движения не содержит. Во-вторых, вы подменяете мой тезис: опыт опровергает не формулу, а ваши рассуждения относительно этой формулы.

Опыт, о котором я говорил - опыт Хафеле-Китинга

Если бы эта ИСО была локальна для каждого объекта, то тогда ситуация "парадокса близнецов" не возникала бы, но она возникает, потому что можно явно указать, какой из "близнецов" прошел большее расстояние в пространстве-времени. Схожий опыт* был проверен на практике.

Ваши рассуждения выше про то, что формулы нужно применять иные, потому там движение непрямолинейное или неравномерное, ошибочны, потому что в опыте* движение было неравномерным и непрямолинейным (неравномерным и круговым вокруг Земли)

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

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

В литературе, занимающейся изучением вопроса, есть она или нет, (и у ряда ученых проходящей по категории научной ереси), такую ИСО называют фундаментальной СО не увлекаемого движением физического вакуума

Согласно формуле, чем быстрее движется объект относительно осей пространства, тем "медленнее" относительно оси времени, и наоборот. Значит, максимальной скоростью относительно оси времени (когда собственное время будет течь быстрее всех) будет обладать объект, который абсолютно покоится по остальным осям. Это и будет максимально достижимый покой относительно покоящегося пространства

  1. С таким количеством контор может и "прокатить"

  2. На нанимающей стороне такие же сидят

Тут надо задаться вопросом для начала, сколько из них соотечественники

Например, точка доступа TP-LINK CPE510 может работать как wi-fi, а может в режиме моста на 10+ километров до такой же парной точки

Когда за продукт отвечали эргономисты, критерием качества была минимизация времени взаимодействия с продуктом (интерфейс должен быть незаметным). Когда туда пришли маркетологи, критерием стала максимизация времени взаимодействия с продуктом (т.н. "вовлеченность")

Красиво. И еще можно поворчать про поколение, не знающее про вращающиеся трансформаторы

1
23 ...

Information

Rating
3,998-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

Chief Technology Officer (CTO), Project Director
Lead
People management
Development management
Building a team
Company management
Development of tech specifications
Project planning
IT service management
Startup management