Merge pull request #4 from khoulwa/fix/fix-typos-18.11

Fixed typos for the last post answer.

questions/_posts/2024-11-18-system-evolution-prediction.md

@@ -135,9 +135,9 @@ tags:
 
 1. Определить контекст рассматриваемой системы;
 2. Определить ограничения и свойства, которые накладываются другими системами (как внешними, так и теми, что внутри бизнеса);
-3. Скорректировать контекст и ограничения спустя N времени. Связано с тем, что система меняется, следовательно контекст также изменится. При этом, ограничения тоже меняются со временем (новые законы, цели и стратегия компании меняется, появляются новые привычки пользователей), что также придется учитывать;
+3. Скорректировать контекст и ограничения спустя N времени. Связано с тем, что система меняется, следовательно, контекст также изменится. При этом, ограничения тоже меняются со временем (новые законы, цели и стратегия компании меняется, появляются новые привычки пользователей), что также придется учитывать;
 
-Важный момент, связанный со сроком ««предсказания»: чем дальше будущее, тем больше вероятности ошибиться. Т.е. предсказать что будет с системой через десять лет будет сложнее (и выводы абстрактнее), чем предсказать, что будет с системой через пол года. Но так как, для большинства решений, необходимо понимать, что будет с системой через 6-12 месяцев, подход будет работать. Что связано с инертностью бизнеса (кроме стартапов) и окружения, влияющего на бизнес. Т.е. изменения происходят не за один день, опять же, кроме «черных лебедей».
+Важный момент, связанный со сроком «предсказания»: чем дальше будущее, тем больше вероятности ошибиться. Т.е. предсказать что будет с системой через десять лет будет сложнее (и выводы абстрактнее), чем предсказать, что будет с системой через пол года. Но так как, для большинства решений, необходимо понимать, что будет с системой через 6-12 месяцев, подход будет работать. Что связано с инертностью бизнеса (кроме стартапов) и окружения, влияющего на бизнес. Т.е. изменения происходят не за один день, опять же, кроме «черных лебедей».
 
 ## На что обратить внимание для понимания контекста и ограничений
 
@@ -190,11 +190,11 @@ tags:
 
 #### Технические ограничения
 
-Это касается как языка и экосистемы, так и версий технологий и используемых подходов. Связано с тем, что фреймворки могут накладывать ограничения, в которых система развивается (привет [convention over configuration](https://en.wikipedia.org/wiki/Convention_over_configuration)){:target="_blank"}. А иногда старые версии критически важных библиотек не позволяют изменить систему так, как требуется по требованиями.
+Это касается как языка и экосистемы, так и версий технологий и используемых подходов. Связано с тем, что фреймворки могут накладывать ограничения, в которых система развивается (привет [convention over configuration](https://en.wikipedia.org/wiki/Convention_over_configuration){:target="_blank"}). А иногда старые версии критически важных библиотек не позволяют изменить систему так, как требуется по требованиям.
 
 #### Государства, законы и социокультурные особенности
 
-Бизнес крутиться в конкретной юрисдикции, значит наша цель – понять что может и не может делать бизнес как в юридических, так и в социо-культурных рамках. Вопросы лучше задавать доменным экспертам.
+Бизнес крутится в конкретной юрисдикции, значит наша цель – понять что может и не может делать бизнес как в юридических, так и в социо-культурных рамках. Вопросы лучше задавать доменным экспертам.
 
 #### Команда разработки и люди
 
@@ -218,7 +218,7 @@ tags:
 ## Советы
 
 - «Черных лебедей» нельзя предсказать (на то и черные лебеди), поэтому модульность и изолированность вечные друзья. Единственное, важно правильно выбрать границы элементов, по опыту определение границ по бизнес элементам/процессам работает в 80% случаев;
-- В стартапах нельзя предсказать во что превратиться бизнес (так ютуб из сайта знакомств стал ютубом и другие примеры). Поэтому по дефолту придерживайтесь модульности через low coupling, high cohesion. При этом, на качество кода в модуле можно забить. А модули лучше выбирать через бизнес гипотезы/фичи (чтобы не уменьшать ТТМ);
+- В стартапах нельзя предсказать во что превратится бизнес (так ютуб из сайта знакомств стал ютубом и другие примеры). Поэтому по дефолту придерживайтесь модульности через low coupling, high cohesion. При этом, на качество кода в модуле можно забить. А модули лучше выбирать через бизнес гипотезы/фичи (чтобы не уменьшать ТТМ);
 - Помните, что ограничения и требования не обязательно собирать самостоятельно. Стоит попросить аналитиков, менеджеров, СТО, архитекторов или кого-то еще помочь;
 - Если работаете разработчиком и нет аналитиков или архитекторов – не заморачивайтесь с ограничениями. Лучше попросите стратегию бизнеса на требуемую часть системы (не путать с техническим сервисом) на ближайшее время. Обычно у бизнеса готов либо документ, либо есть представление в голове куда надо идти и что делать как минимум на полгода вперед. Плюс спросите СТО что по технической стратегии. Этого хватит;
 - Системный контекст подойдет не только для «предсказаний», но и для создания технической стратегии в компании. Например, [zachman framework](https://en.wikipedia.org/wiki/Zachman_Framework){:target="_blank"} использует похожие идеи;