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

Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.

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

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

Поэтому оставшиеся в игре уже примерно одинаково в широком диапазоне представляют себе крупноблочное ЧТО следует делать, ЧТО хорошо и ЧТО плохо. Многие знают, ЧТО хорошо, но намного меньшее число справляются с тем, КАК этого реально добиться с ограниченным ресурсом.

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

Условно, Иванов знает, что нужен рефакторинг, и Петров знает, что нужен рефакторинг. Говорят и думают они про него одинаково. Но Иванов выкрутился и нашел двух человек на задачу, а Петров нет. Иванов сделал рефакторинг, Иванов молодец.

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

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

Оглядываясь назад на какие-то неудачи, бывает видно, где можно было дожать еще немного и очень вероятно, что избежать. Такие взгляды назад, кстати, это ад для перфекционистов. Не отказываясь от анализа ошибок, стоит как-то приучить себя жить с 70-80% успеха и быть ими довольными, примерно как формулируют задачи в ОКР.

TL:DR; есть довольно много людей, которые стремятся к хорошему ЧТО, но его достижение это вопрос "мелких" КАК

Разумеется, никогда нельзя забывать, ради чего все эти мелкие КАК делаются