Jira

Это который из серии «Сова - эффективный менеджер»?

Я читал, а ты читал? Особенно я имею в виду

Welcome changing requirements, even in late development

Best architectures, requirements, and designs emerge from self-organizing teams

Скажи мне, где ты увидел ПРЕДПИСАНИЕ не иметь архитектуры? В принципе «приветствуйте изменения, даже на поздних этапах разработки»?

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

Во-первых, если любое изменение, включая изменение шрифта в админке, ведет у тебя к изменению архитектуры всей системы - ты что-то делаешь ОЧЕНЬ не так. Хорошая, продуманная архитектура позволяет сделать очень много, оставаясь в существующих рамках. Собственно, этот пункт как раз и стимулирует использовать гибкую, устойчивую к изменениям архитектуру.

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

Соглашусь. Лучше уж с Jira чем без нее. Ну а если надо что попроще (хотя не факт что проще а не тупее) то есть еще Trello.

Скажи мне, где ты увидел ПРЕДПИСАНИЕ не иметь архитектуры? В принципе «приветствуйте изменения, даже на поздних этапах разработки»?

Скажи мне, где ты увидел чтобы у меня было написано «не иметь архитектуры»? Особенно учитывая наличие уже двух ответов на эту тему.

В принципе «приветствуйте изменения, даже на поздних этапах разработки»?

Вы придумали архитектуру, но в итоге сделали мимо нее — вся история.

Во-первых, если любое изменение, включая изменение шрифта в админке, ведет у тебя к изменению архитектуры всей системы - ты что-то делаешь ОЧЕНЬ не так

Я тебя удивлю, но даже в waterfall изменение шрифта в админке может быть допустимо на позднем этапе, если дизайн страниц был назначен на поздний этап:
https://ru.wikipedia.org/wiki/Каскадная_модель
«После того, как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того, как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки.»

Снова напоминаю про сову:
https://pikabu.ru/story/sova__yeffektivnyiy_scrum_master_6341122

Соглашусь. Лучше уж с Jira чем без нее. Ну а если надо что попроще (хотя не факт что проще а не тупее) то есть еще Trello

Есть гора разных альтернативных трекеров, про часть которых уже написали, но на саомм деле их валом: bugzilla, roundup, redmine, trac, mantis — тысячи их. Trello, на мой взгляд — это уж слишком просто, уже на уровне сотен багов начнутся проблемы.

Скажи мне, где ты увидел чтобы у меня было написано «не иметь архитектуры»? Особенно учитывая наличие уже двух ответов на эту тему.

ОК, принимается, ты писал, цитирую, «Agile вообще предписывает не иметь заранее определенной архитектуры». Но не иметь заранее, еще до начала проекта, определенной архитектуры - это нормально. Да, у всех есть свои наработки, но потом их приходится приводить в соответствие с конкретными условиями.

И еще один момент - Agile ничего не предписывает. Как и любая другая методология управления проектами - это набор рекомендаций и лучших практик, который надо воспринимать не как Священное Писание, а как набор рекомендаций и лучших практик.

Вы придумали архитектуру, но в итоге сделали мимо нее — вся история.

Если ты что-то сделал мимо архитектуры решения - ты сделал плохо, Agile тут не при чем.

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

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

У пацанов и спрашивай

У тебя чот не то с английским языком. Попробуй хотя бы гуглтранслейт, что ли.

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

У тебя опять какие-то странные фантазии прорываются. Повторю в последний раз: PM - это устойчивая аббревиатура в коммерческой разработке ПО.

https://en.wikipedia.org/wiki/PM

Terminology

Performance management of an organisation
Preventive maintenance
Project manager

В компьютере есть четыре основных ресурса: ввод-вывод, сетевая пропускная способность, память и процессор.

Молодец. Предлагаешь экономить на IO за счет остальных составляющих?

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

Хорошие менеджеры. Большинство менеджеров, которых я встречал просто некомпетентные болваны, мешающие коллективу работать. Почему-то в РФ гораздо больше беда с компетентными менеджерами, чем с компетентными разработчиками. Может потому что в менеджеры массово идут люди с недостатком мозгов в голове, а может ещё по каким-то причинам. Для меня это загадка.

менеджер прикидывает, нужно ли клиента послать с этой просьбой

И вот прямо в этом моменте менеджер не понимает, какая хотелка реализуется в 2 пинка, а какая требует смены всей архитектуры проекта.

закипел тимбилдинг, полетел фалафель, пар от вейпов выедал глаза

Ахаха, что ты делаешь, демон, прекрати.

Но не иметь заранее, еще до начала проекта, определенной архитектуры - это нормально

Ну, и как вы собрались потом собирать проект? Если постановку требований и проектирование делать вначале — вуаля, у вас уже наполовину каскадная модель.

И еще один момент - Agile ничего не предписывает. Как и любая другая методология управления проектами - это набор рекомендаций и лучших практик, который надо воспринимать не как Священное Писание, а как набор рекомендаций и лучших практик

Ага, типа «если продукт написан хорошо — это аджайл, если плохо — значит, аджайлу следовали плохо».

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

Я с самого начала ставил проблему определения. Ваше определение Agile почему-то до боли напоминает итеративную разработку. Аджайл вполне конкретно ставит рамки, что «сделать релиз > написать по-настоящему работающий софт», «изменение архитектуры > следование плану», «общение > доки и организованные процессы», и если у вас знак сравнения стал направлены в другую сторону, то, вполне возможно, у вас уже не аджайл.

В компьютере есть четыре основных ресурса: ввод-вывод, сетевая пропускная способность, память и процессор.

Молодец. Предлагаешь экономить на IO за счет остальных составляющих?

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

Почему-то в РФ гораздо больше беда с компетентными менеджерами, чем с компетентными разработчиками. Может потому что в менеджеры массово идут люди с недостатком мозгов в голове, а может ещё по каким-то причинам. Для меня это загадка

Причины две: их не так много и их тяжело находить. Обычно для отбора приходится нанимать более-менее подходящих, а потом из них отбирать самых адекватных. При этом, конечно же, хочется заплатить менеджеру поменьше. Toptal решает проблему просто — прогеры сами общаются с заказчиком. Такой вот Agile. Тоже разумно.

И вот прямо в этом моменте менеджер не понимает, какая хотелка реализуется в 2 пинка, а какая требует смены всей архитектуры проекта

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

p.s. начинает пованивать сишечкой А никто и не сомневался, что ты - хипстер!

Это если менеджер хороший. А таких мало. Ну и с разрабами он должен плотно общаться в обе стороны. А обычно он только в одну умеет и в худшем случае бывает как-то так (сам был свидетелем такого). Клиент сказал хотелку -> Менеджеру идея понравилась и он не долго думая согласился -> Менеджер отчитался боссу под козырёк что всё будет сделано через неделю -> Менеджер пришел к разрабам и дал указание сделать велосипед, чтоб на Луну катался и чтобы был реализован уже вчера -> IT отдел уволился. Сроки сорваны, клиент ушел с мыслью о том, что простые вещи реализовать за короткий срок не могут, Босс думает, какие же тупые разрабы, менеджер ищет новую работу.

Ну, и как вы собрались потом собирать проект?

Я не понимаю твоего вопроса.

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

Мне иногда кажется, что ты споришь не со мной, а с головами в своей голове.

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

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

Ага, типа «если продукт написан хорошо — это аджайл, если плохо — значит, аджайлу следовали плохо».

Нет. Типа, никакая методология вам не гарантирует хороший результат. Добро пожаловать в реальность.

Я с самого начала ставил проблему определения. Ваше определение Agile почему-то до боли напоминает итеративную разработку. Аджайл вполне конкретно ставит рамки, что «сделать релиз > написать по-настоящему работающий софт», «изменение архитектуры > следование плану», «общение > доки и организованные процессы», и если у вас знак сравнения стал направлены в другую сторону, то, вполне возможно, у вас уже не аджайл.

«сделать релиз > написать по-настоящему работающий софт»

Откуда ты это взял? И что значит «по-настоящему работающий»? Назови, пожалуйста, принцип или ценность agile, из которого ты это вывел.

«изменение архитектуры > следование плану»

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

«общение > доки и организованные процессы»

И это тоже правильно. Бюрократия на проекте должна быть в минимально необходимом объеме.

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

С какого бока это аджайл? Может, они еще и на шашлыки должны на выходных выезжать вместе?

У нас есть некоторые точки невозврата, после которых изменения почти невозможны

Аджайл — такой аджайл. Что там было про «Welcome changing requirements, even in late development»?

«сделать релиз > написать по-настоящему работающий софт»

И что значит «по-настоящему работающий»? Назови, пожалуйста, принцип или ценность agile, из которого ты это вывел

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

Customer satisfaction by early and continuous delivery of valuable software
Deliver working software frequently (weeks rather than months)
Working software is the primary measure of progress

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

В оригинале звучить как «Welcome changing requirements», что значит «приветствовать изменение требований», то есть, поощрять возможные изменения на поздних этапах.

С какого бока это аджайл? Может, они еще и на шашлыки должны на выходных выезжать вместе?

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

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

Аджайл — такой аджайл. Что там было про «Welcome changing requirements, even in late development»?

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

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

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

Customer satisfaction by early and continuous delivery of valuable software

Deliver working software frequently (weeks rather than months)

Working software is the primary measure of progress

Перевожу на русский:

• Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.

• Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

• Работающий продукт — основной показатель прогресса.

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

Где тут про забагованное говно? Там, вроде, человеческим языком сказано - поставлять надо работающий продукт.

В оригинале звучить как «Welcome changing requirements», что значит «приветствовать изменение требований», то есть, поощрять возможные изменения на поздних этапах.

Эммм, не знаю. «Приветствовать изменения» - это значит «приветствовать изменения», то есть, принимать запросы и спокойно отрабатывать. А «поощрять изменения» - это если вы начнете бегать вокруг заказчика и предлагать ему внести изменения.

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

Эдуард, вы?

Факт лишь в том, что он сказал чуть, и теперь не может признать свою ошибку. Но в это плане он не отличается от 99% людей. Особенно здесь. (Большей концентрации баранов я в своей жизни не встречал.)

чуть

чушь

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

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

Короче, опять какие-то фантазии из мира олимпиадного программирования.

В оригинале звучить как «Welcome changing requirements», что значит «приветствовать изменение требований», то есть, поощрять возможные изменения на поздних этапах.

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

Смысл этого предложения - «не принимать изменения требований в штыки».

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

Ты по той же логике можешь с форума свалить.

Не могу, в интернете же кто-то не прав! =)

Нет ты %)

Не мучай его - ему jira жмет. Он в самом начале на это жаловался.

Ну да. Вначале была чудесная перепись инвалидов от разработки. Жаль не успел к банкету.

english, английский, английский язык

Подозреваю, что инвалид от разработки — это как раз ты.

byko3y , вбрасываю Fossil. Просто, нулевой вход и то же самое, но по минимуму. И по-царски.

А, не, похоже, не по-царски. Но близко.

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

Где это происходит? Даже на режимных заводах и атомных электростанциях такого ада не происходит. Да, могут присутствовать ограничения на доступ к документации, но не к устному общению. Как ты вообще собрался контролировать это самое устное общение? Ты в курсе, как КГБ ближе к концу 20-го века получилось кучу американских технологий? Брали из института людей с высшим образованием, отправляли за океан, где они корешились с местными учеными, и слово за слово вытаскивали по кусочкам инфу о перспективных разработках. Идея американского руководства заключалась в том, что ни один отдельный ученый не знает всей картины, потому даже целенаправленное предательство не могло привести к серьезной утечке технологий. Однако они не могли предположить, что масштаб подготовки ученых-разведчиков и масштаб утечки по кускам настолько огромен, что в КГБ могли собрать цельную картину.

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

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

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

Я понял, в чем причина нашего недопонимания, и сейчас я тебе объясню на таком примере, как Agile Waterfall организация проекта (гибкая каскадная разработка). У нас есть проект на модификацию софта, срок реализации — 3 недели, где тестовый релиз запланирован на вторую неделю, и последняя неделя запланирована на исправление багов. Что там нам еще не хватает для аджайла? Ах да, нужно много общаться — это не проблема, будем много общаться. И что у нас получается? Частые релизы есть? Есть, через две недели и через неделю релизимся. Общение есть? Есть. Гибкость на последнем этапе есть? Есть. Вуаля, это Agile Waterfall. Если подумать, то каждая итеративная разработка — это и есть набор отдельных каскадных разработок.

Итак, манифест Agile редакции 2020 года:

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

Несложно заметить, что это какая-то лютая маркетинговая чушь, и, тем не менее, это не более, чем перевод-пересказ оригинального манифеста Agile.

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

Должен заметить, что меня не перестает радовать фраза:

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

Наивысшим приоритетом в отношениях с клиентом должна быть поставка любви и добра — вот каков главный тезис Agile.

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

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

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

Вообще по управлению проектами книжки есть, их можно читать даже разработчикам. Попробуй как-нибудь.

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

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

Твоя проблема в том что ты про Agile кроме слухов, которые передаются бородато-сарафанным радио от кухни к кухне, ничего не читал

Знаешь, чтение книжек по Agile мне напоминает чтение брошюрок свидетелей Иеговы. Это то же самое сектанство про всё хорошее против всего плохого, просто вместо обогащения проповедников христианства обогащаются проповедники вкалывания на работе и заинтересованные в этом лица.

Agile - это не только манифест, это набор приемов, которые помогают реализации того, что манифест декларирует

Да, молитвы, покаяния, проповеди среди больных раком — я уже проходил это.

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

«Книга правил (полное название: Книга правил святых апостол, святых соборов вселенских и поместных и святых отец) — сборник церковных канонов (правил), составляющих канон православной церкви, основной источник канонического права Русской православной церкви»

Знаешь, чтение книжек по Agile мне напоминает чтение брошюрок свидетелей Иеговы.

Не читал, но глубоко возмущен, да.

Ну продолжай черпать сведения из флеймов на форумах. Манифест вон уже осилил, а страниц через 100 флейма глядишь и до предисловия доберешься.

Ну продолжай черпать сведения из флеймов на форумах. Манифест вон уже осилил, а страниц через 100 флейма глядишь и до предисловия доберешься

Зачем? У меня же есть двенадцать заповедей Agile, как двенадцать апостолов Христа.

У меня же есть двенадцать заповедей Agile

Так ты же не понимаешь их смысла, дополнительные объяснения требуются %)

Окей. Давай с конкретными примерами. Что делает твое приложение, сколько ресурсов ему требуется, и как ты его можешь отмасштабировать? ? Сколько в нем строк кода, на каком языке?

Несложно заметить, что это какая-то лютая маркетинговая чушь, и, тем не менее, это не более, чем перевод-пересказ оригинального манифеста Agile.

- И шо вы все с ума посходили со своим Карузо?! Слышал я вашего Карузо - картавит, шепелявит...
- Вы были на концерте???
- Нет, мне Рабинович по телефону напел.

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

это у вас эджайл неправильный, вы чеклист не поняли, вот купите у нас курс и все сразу станет как надо

вы тупые просто и курсов не понимаете, вот купите у нас коуча, вот и выстроит он у вас процессы как надо

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

Соболезную

Что делает твое приложение, сколько ресурсов ему требуется, и как ты его можешь отмасштабировать? ? Сколько в нем строк кода, на каком языке?

Паскаль, PHP, JS, пишем CRM, бухгалтерию, документооборот. Примерно как 1С, только с минимальными затратами на подготовку системы. Старая система была за миллион строк и много чего делала на стороне клиента, новая система на JS SPA чуть меньше сотни тысяч и все равно достаточно скромно нагружает сервер... по крайней мере сейчас.

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

Я не особо заинтересован лично заниматься этой проблемой, но если у кого-то будут интересные замечания плана «лошара, это ж можно легко сделать на софтнейме применив методнейм» — всегда пожалуйста. На мой взгляд эта проблема эффективно не решается. и лучшее, что можно сделать — это просто ускорить доступ к хранилищу, как то быстрые SSD диски и много кэша. Естественно, когда хранилища перестают быть узким местом, то внезапно узким местом становится процессор, а я даже не знаю такого готового движка БД, который умел бы сам просеивать в несколько потоков кучу байт — для такого обычно берут минимальную прослойку-хранилище и пишут свой собственный скоростной код.

Сразу спешу остановить любителей шардирования, и советую подумать, как вы будете делать выборку/сортировку/группировку по произвольным полям, когда у вас отдельные куски данных хранятся на разных серверах. Я не спорю, что есть разные хитроумные решения этого вопроса, но особенность их заключается в том, что они расчитаны под конкретную структуру данных и запросов к ним, а у нас единственная структурированность — это связь N-к-M для двух наборов данных.

Паскаль, PHP, JS, пишем CRM, бухгалтерию, документооборот

а разговоров-то было

Паскаль, PHP, JS, пишем CRM, бухгалтерию, документооборот

А я не спорю, что это говнище и давно мне было пора сваливать оттуда.