Некоторый парадокс получается с применением AI для автоматических переводов. Мы переводим продукт на очень много языков и это стоит приличных денег, поэтому такая оптимизация интересна. Но это все-таки не рилзы переводить, продукт платный, есть ответственность и есть какие-то стандарты качества.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.
И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу
Вообще история авто-переводов у нас очень старая, и впервые это было опробовано свыше 20 лет назад (полная катастрофа, закопать и не возвращаться), потом еще раз 10 лет назад (г..но, но для галочки с большой натяжкой можно), ну и вот теперь это вполне рабочий метод с некоторыми ограничениями.
По моим наблюдениям основатели небольших компаний при их поглощении "стратегом" (бОльшим бизнесом) не часто приживаются. Сужу как по знакомым, так и по статьям от поглощенных в гугл, мс и тп, так и по нашей конторе. Детальных примеров в памяти уже довольно много, так что можно что-то субъективно обобщить:
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.
- Если основатель желал возглавить усиленный рост своего детища, то типовая история, что компания видит это рост совершенно иначе, иными средствами и методами, и основатель начинает конфликтовать, оказывается неудобным, после чего его отодвигают и прощаются с ним.
- Основатель небольшой компании привык всем заниматься понемногу, быть человеком-оркестром, принимать массу решений во всех областях. В бОльшой компании его функции разбирают по отделам - там продажи, тут маркетинг, там тех.поддержка, здесь разработка, там финансы. По моим наблюдениям, очень сложно психологически отказаться от "оркестровой" сущности и выбрать какую-то одну специализацию. А даже и при желании специализироваться - оказывается, что в каждой конкретной функции основатель не слишком высоко котируется - узкие специалисты большой конторы более прокачаны.
- Казалось бы оптимально основателю стать продакт менеджером своего продукта, но часто оказывается что созданое решение это функция удачи и обстоятельств. Удачно упавшее зернышко, которое заботливо выращено своими руками. При этом человек не привык работать с командой, формулировать задачи и планы, не привык убеждать и доказывать, руководит по принципу "делай как я, делай что я сказал". Нет возможности что-то масштабировать при таком подходе, команды не хотят работать с таким продакт менеджером.
- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.
Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.
Вобщем, если бы я сделал небольшую компанию и мне предложили продаться, то из этого опыта (с покупающей стороны) я бы очень сильно подумал, чего я на самом деле хочу и на что я для этого готов.
Хорошая нота это что какие-то приличные деньги люди в итоге забирают, просто позже и меньше, чем хотели, и с каким-то неприятным опытом по пути.
Никакой пользы в этой заметке, но однако забавно какой путь в признании проделал слак за эти годы
- баловство для отдельных гиков в инженерке, инженерное руководство косится с подозрением
...
- разработка наглухо подсела на слак, инженерное руководство придумывает правила пользования/модерации, соседнии отделы игнорируют и морщатся, периодически грозятся прикрыть (но это уже нереально)
...
- вся компания сидит в слак, попытки его грохнуть забыты, но по серьезным вопросам "продублируйте в почту"
...
- пожилые очень бизнесовые дядечки говорят, что хватить уже пожалуйста мусорить в почте, давайте пожалуйста все в слак - нам так удобнее. Серьезная веха.
Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)
- баловство для отдельных гиков в инженерке, инженерное руководство косится с подозрением
...
- разработка наглухо подсела на слак, инженерное руководство придумывает правила пользования/модерации, соседнии отделы игнорируют и морщатся, периодически грозятся прикрыть (но это уже нереально)
...
- вся компания сидит в слак, попытки его грохнуть забыты, но по серьезным вопросам "продублируйте в почту"
...
- пожилые очень бизнесовые дядечки говорят, что хватить уже пожалуйста мусорить в почте, давайте пожалуйста все в слак - нам так удобнее. Серьезная веха.
Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)
К вопросу о возвращении в офисы - в этой карикатуре есть большая доля правды.
Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.
В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.
В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.
И с тех пор этот процесс успел усугубиться тем, что за период повсеместной удаленности команды только больше перемешались, поэтому близость в физическом офисном пространстве уже давно не означает совместной работы - коллеги могут быть в офисе, но в совсем другом.
Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.
В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.
В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.
И с тех пор этот процесс успел усугубиться тем, что за период повсеместной удаленности команды только больше перемешались, поэтому близость в физическом офисном пространстве уже давно не означает совместной работы - коллеги могут быть в офисе, но в совсем другом.
Наверное уже все слышали, про шумное исследование, что 10% инженеров в компаниях (смотрели на выборку в 50 тыс человек) не делают практически ничего.
Не то, чтобы нельзя было такого допустить - в достаточно большой компании, наверное, и слона спрятать можно.
Но к сожалению, статья (первоисточник) не отвечает достаточно детально про методику сбора данных. А то на моей памяти был случай, что установили моим бывшим коллегам софтинку, которая считала их продуктивность с оплатой по часам. И этот софт за продуктивность считал кодинг, а вот например сидение в терминале за настройкой и отладкой инфраструктуры он продуктивным делом не считал, к некоторой печали инженеров. Вот такой был "налог" на инфраструктурные задачи - но вроде оно там достаточно равномерно распределялось по людям, чтобы никого не задевать смертельно.
А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.
https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing
Не то, чтобы нельзя было такого допустить - в достаточно большой компании, наверное, и слона спрятать можно.
Но к сожалению, статья (первоисточник) не отвечает достаточно детально про методику сбора данных. А то на моей памяти был случай, что установили моим бывшим коллегам софтинку, которая считала их продуктивность с оплатой по часам. И этот софт за продуктивность считал кодинг, а вот например сидение в терминале за настройкой и отладкой инфраструктуры он продуктивным делом не считал, к некоторой печали инженеров. Вот такой был "налог" на инфраструктурные задачи - но вроде оно там достаточно равномерно распределялось по людям, чтобы никого не задевать смертельно.
А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.
https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing
404 Media
Are Overemployed ‘Ghost Engineers’ Making Six Figures to Do Nothing?
"We have data on the performance of >50k engineers from 100s of companies. ~9.5% of software engineers do virtually nothing: Ghost Engineers.”
Пока все репостят скандал с провели опрос по удовлетворенности и уволили всех неудовлетворенных, попробуем быть на шаг впереди и прочтем, что автор первого поста описывает это как PR ход. Завирусилось знатно, надо признать.
Невозможно, конечно, точно сказать было ли это реально PR ходом или оперативно переиграли.
https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/
Невозможно, конечно, точно сказать было ли это реально PR ходом или оперативно переиграли.
https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/
Помните смешной текст про то, что все животные делятся на
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.
Я с подобным периодически болезненно сталкиваюсь. Например, вот возник список клиентов и категории "которым надо позвонить" и "которым звонили". Технически это два независимых флага, сочетания которых гибко передают все богатство сочетаний - и не надо было звонить, но позвонили, и надо было, но еще нет. Но жить с таким трудно - когда эти данные циркулируют, то возникает лишняя когнитивная нагрузка и риски неправильной интерпретации. Например, "надо было позвонить 9м и позвонили 9м - о, все процесс закончен! - нет, еще двум надо позвонить - как так? - ну позвонили двум, которым не надо, а двое, которым надо, еще остались...".
Это может показаться смешным, может показаться нестоящим внимания, но об подобное люди спотыкаются, тратят время каждый раз на выяснение, периодически делают вокруг этого ошибки. Если таких процессов много, или если они большие, или если они важные - это создает паразитную когнитивную нагрузку в организации. Подобное стоит вычищать и предотвращать, чтобы не похоронить организацию под горой путаницы, неуверенности и ложных интерпретаций.
Этот конкретный пример из процесса продажников, но такая же задача возникает в рефакторинге, в реорганизациях, в изменениях интерфейса продуктов - кому, что ближе.
Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.
Тогда относительно простые инструменты и минимум внимания позволяют с минимумом ошибок переваривать довольно массивные критические проекты (в смысле, что ошибки в них очень дорого обходятся).
Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.
Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.
Я с подобным периодически болезненно сталкиваюсь. Например, вот возник список клиентов и категории "которым надо позвонить" и "которым звонили". Технически это два независимых флага, сочетания которых гибко передают все богатство сочетаний - и не надо было звонить, но позвонили, и надо было, но еще нет. Но жить с таким трудно - когда эти данные циркулируют, то возникает лишняя когнитивная нагрузка и риски неправильной интерпретации. Например, "надо было позвонить 9м и позвонили 9м - о, все процесс закончен! - нет, еще двум надо позвонить - как так? - ну позвонили двум, которым не надо, а двое, которым надо, еще остались...".
Это может показаться смешным, может показаться нестоящим внимания, но об подобное люди спотыкаются, тратят время каждый раз на выяснение, периодически делают вокруг этого ошибки. Если таких процессов много, или если они большие, или если они важные - это создает паразитную когнитивную нагрузку в организации. Подобное стоит вычищать и предотвращать, чтобы не похоронить организацию под горой путаницы, неуверенности и ложных интерпретаций.
Этот конкретный пример из процесса продажников, но такая же задача возникает в рефакторинге, в реорганизациях, в изменениях интерфейса продуктов - кому, что ближе.
Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.
Тогда относительно простые инструменты и минимум внимания позволяют с минимумом ошибок переваривать довольно массивные критические проекты (в смысле, что ошибки в них очень дорого обходятся).
Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.
Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку
Смотрел, что недавно в confluence выкатили функции встроенных баз данных - очень прикольная штука, но оказалось, что к ним еще не был готов бекап/рестор, что для более-менее крупной организации, конечно стопор для активного использования. Это заставило задуматься еще раз про в каких местах правильно срезать углы, если надо выкатить продукт пораньше.
Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.
Тогда это несколько необычно было, пытались писать полные требования со всеми нужными функциями, а потом по ним реализовывать.
Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.
Тогда это несколько необычно было, пытались писать полные требования со всеми нужными функциями, а потом по ним реализовывать.
В деле управления большой командой и отделом вдолгую пришел к выводу, что куда важнее КАК делать в деталях, чем ЧТО крупноблочно делать. Поясню - дело в том, что неправильное масштабное ЧТО приводит к достаточно быстрой деградации и вылетанию с дистанции. И на этом дальнейшая судьба участника нам уже не интересна.
Поэтому оставшиеся в игре уже примерно одинаково в широком диапазоне представляют себе крупноблочное ЧТО следует делать, ЧТО хорошо и ЧТО плохо. Многие знают, ЧТО хорошо, но намного меньшее число справляются с тем, КАК этого реально добиться с ограниченным ресурсом.
В реальных ресурсах совершенно невозможно одинаково хорошо успевать везде, поэтому чтобы успеть где-то, где-то в другом месте надо опоздать. Надо ужать ресурс в одном месте, чтобы успеть больше в другом, потому что там важнее. Но и продолбать совсем нельзя, поэтому "все горит и ты в огне", а в это самое время реальную разницу по капельке создают разные на первый взгляд мелкие приемы, чуть более эффективные практики здесь, срезание каких-то углов там. Все, чтобы собрать нужный ресурс в нужных местах, но и нигде не оголиться и не допустить критический крах. Вот эти вот "мелкие маневры" в итоге и позволяют получить хорошее ЧТО.
Условно, Иванов знает, что нужен рефакторинг, и Петров знает, что нужен рефакторинг. Говорят и думают они про него одинаково. Но Иванов выкрутился и нашел двух человек на задачу, а Петров нет. Иванов сделал рефакторинг, Иванов молодец.
К сожалению, в этих маневрах плохо работают какие-то универсальные простые принципы. Хорошее для одной ситуации, оказывается плохим для другой. Требуется хитрый баланс, правильная расстановка именно под конкретную ситуацию. Вот именно его я здесь называю КАК.
Это примерно как в шахматах нельзя сказать, что вот такой ход правильный или неправильный - он таким становится в конкретной ситуации. Где-то и ферзя сдавать нормально. Есть какие-то понятные критерии, есть понятный набор приемов, но воплотить из них одних выигрыш трудно. Выигрыш складывается из где-то выигранной пешки, где-то выдвижения фигур чуть раньше. Тоже самое и в наших проектах - каждый небольшой выигрыш здесь, это возможность сосредоточить бОльшее усилие там.
Оглядываясь назад на какие-то неудачи, бывает видно, где можно было дожать еще немного и очень вероятно, что избежать. Такие взгляды назад, кстати, это ад для перфекционистов. Не отказываясь от анализа ошибок, стоит как-то приучить себя жить с 70-80% успеха и быть ими довольными, примерно как формулируют задачи в ОКР.
TL:DR; есть довольно много людей, которые стремятся к хорошему ЧТО, но его достижение это вопрос "мелких" КАК
Разумеется, никогда нельзя забывать, ради чего все эти мелкие КАК делаются
Поэтому оставшиеся в игре уже примерно одинаково в широком диапазоне представляют себе крупноблочное ЧТО следует делать, ЧТО хорошо и ЧТО плохо. Многие знают, ЧТО хорошо, но намного меньшее число справляются с тем, КАК этого реально добиться с ограниченным ресурсом.
В реальных ресурсах совершенно невозможно одинаково хорошо успевать везде, поэтому чтобы успеть где-то, где-то в другом месте надо опоздать. Надо ужать ресурс в одном месте, чтобы успеть больше в другом, потому что там важнее. Но и продолбать совсем нельзя, поэтому "все горит и ты в огне", а в это самое время реальную разницу по капельке создают разные на первый взгляд мелкие приемы, чуть более эффективные практики здесь, срезание каких-то углов там. Все, чтобы собрать нужный ресурс в нужных местах, но и нигде не оголиться и не допустить критический крах. Вот эти вот "мелкие маневры" в итоге и позволяют получить хорошее ЧТО.
Условно, Иванов знает, что нужен рефакторинг, и Петров знает, что нужен рефакторинг. Говорят и думают они про него одинаково. Но Иванов выкрутился и нашел двух человек на задачу, а Петров нет. Иванов сделал рефакторинг, Иванов молодец.
К сожалению, в этих маневрах плохо работают какие-то универсальные простые принципы. Хорошее для одной ситуации, оказывается плохим для другой. Требуется хитрый баланс, правильная расстановка именно под конкретную ситуацию. Вот именно его я здесь называю КАК.
Это примерно как в шахматах нельзя сказать, что вот такой ход правильный или неправильный - он таким становится в конкретной ситуации. Где-то и ферзя сдавать нормально. Есть какие-то понятные критерии, есть понятный набор приемов, но воплотить из них одних выигрыш трудно. Выигрыш складывается из где-то выигранной пешки, где-то выдвижения фигур чуть раньше. Тоже самое и в наших проектах - каждый небольшой выигрыш здесь, это возможность сосредоточить бОльшее усилие там.
Оглядываясь назад на какие-то неудачи, бывает видно, где можно было дожать еще немного и очень вероятно, что избежать. Такие взгляды назад, кстати, это ад для перфекционистов. Не отказываясь от анализа ошибок, стоит как-то приучить себя жить с 70-80% успеха и быть ими довольными, примерно как формулируют задачи в ОКР.
TL:DR; есть довольно много людей, которые стремятся к хорошему ЧТО, но его достижение это вопрос "мелких" КАК
Разумеется, никогда нельзя забывать, ради чего все эти мелкие КАК делаются