Про тактичні і стратегічні рішення

Мабуть в кожного був такий діалог.

ПМ: Є таска!
Я: Яка?
ПМ: В нас в системі є юзери і адміни, зроби в адмінці так щоб адміни могли міняти дані юзера.
Я: Г*вно вопрос!
...
ПМ: Менеджери не можуть в аппку зайти! Вася, Петя допоможіть розібратись!
Вася: Ну всьо правильно! Ти міняв збереження юзерів?
Я: Міняв..
Петя: В нас коли менеджери заходять в аппку то юзер в БД сам записує дату коли той зайшов останній раз от це і валиться. Бо ти при збережені перевіряєш чи в адміна є права міняти, а менеджер ще тоді не проініціалізувався.
Я:...

Підгорає!

Короче, до чого це все? Мабуть у багатьох так було коли на великих проектах міняєш якийсь невеликий функціонал, а валиться півпроекта. От, в мене недавно так і сталось, робив зміну юзерів в адмінці, а в результаті менеджери не змогли в свої аппки зайти. Бувало і гірше:

— Я тільки html форму логіна поправив, а на проекті система бекапів лягла. ©

Випадок не мій, але я був свідком цього. І це сталось в супер крутого сеньйора який є мега крутим програмістом. Без жартів. В сеньйорів також факапи бувають.
І я от став думати як так стається, і ви мені скажете ну так, все правильно, велика зв’язаність компонентів системи, неправильно продумана архітектура, погано підібране рішення. І ви в принципі будите праві. Але хто винний в цьому? Дев, який на початках писав цей функціонал? Лід, який на початках розробляв архітектуру? ПМ, який ставив задачу? І, насправді, ніхто не винний. Чому? Тому що я вже давно прийшов до того висновку, що коли проект написаний і він працює значить він правильно написаний. Якщо ти вважаєш, що ти класний і знаєш як написати простіше і без багів, і з крутішою масштабованістю то будь добрий, напиши машину часу, перемістись в той період, і підкажи цим трьом персонажам як правильно тому, що в майбутньому хтось через них пох*рить проект. Не можеш? То не настільки ти і класний або просто не розказуй як треба було робити постфактум. Отже, то рішення яке цими трьома персонажами було прийняте тоді і було правильне тому, що зараз проект працює і бізнесу він приносить гроші (банально, правда?), і не важливо, що воно якесь не «елегантне», «фігове» і «можна ж було краще», тебе в той час прийняття цього рішення не було і ти не знаєш чому так сталось, значить це правильне рішення і нема чого його осуджувати. Іншими словами, ніхто технічний борг не відміняв.
І я для себе зрозумів як він з’являється, і як він примножується. Все почалось (не все насправді, але це показовий приклад) з отакого:

ПМ: треба новий функціонал.
Я: давайте побудуємо його на базі отакої архітектури...

... розпинаюсь про принцип нової архітектури ...

ПМ: все класно, все супер, ти канєшно крут, але то такий мінімальний функціонал який не буде в майбутньому розширятись, нам треба щось простеньке, а твоя оця вся архітектура це для великих проектів. Ти просто візьми одну функцію там напиши, нам цього буде достатньо.
Я: ...

І отут я зрозумів, що ПМ прийняв тактичне рішення тобто ситуативне, тобто він не передбачив, що в майбутньому через когось, якогось іншого дева, менеджери не зможуть в аппку зайти. Так ПМу хочеться щоб таска була швидко закрита, і в принципі то є простий функціонал, і типу це ж просто одну функцію написати. Але завтра він приходить зі словами: «Там той функціонал треба трішки доробити, воопше фігню...». А далі точно як в тому відомому приколі про острів, швабри які тримають стелю і вентилятор. І отак з’являється, і виростає технічний борг. І тут, в принципі, багато Пмів та і багато девів скажуть, краще якесь погане рішення і робоче ніж все життя шукати якийсь «ідеальний код», ти ж бл*ть сам вище писав! Так писав. Є така фраза дуже популярна в гуманітаріїв (сам був, сам використовував. Так я світчер):

— Нєт прідєла совєршенству! ©

Всі ж чули як якийсь художник або якийсь письменник 5-10-15-20 років писав одну картину-книгу «Бо хотів відтворити ідеальні форми у своєму творі». От якраз ця фраза не працює в айті.
І для себе я зрозумів ось таке. Якщо ти розумієш що в майбутньому це рішення може призвести до якихось факапів то треба придумати краще рішення, тобто прийняти більш стратегічне рішення. Якщо на даний момент ти не можеш знайти краще рішення і немає в кого спитати як краще це зробити або затрачений час на реалізацію кращого рішення в десятки (тут слово «десятки» треба підкреслити тому, що ПМ зазвичай любить гіперболізувати) разів більший чим на реалізацію гіршого то гірше рішення буде правильнішим. Тобто, по суті, треба тримати баланс. Як його тримати? Де той баланс? Поняття відносне і кожен сам вирішує. Я вважаю, якраз досвід програміста частково характеризується вмінням тримати цей баланс. Але приймати краще стратегічні рішення чим тактичні.

Ось такий коротенький приклад, що таке тактичні рішення і чим кращі стратегічні.

Завіса...

В мене все. Сорі за матюки. Просто трішки підгоріло) За критику велике дякую. Можете мене бити мокрими тряпками.