×Закрыть

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

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

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

Підгорає!

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

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

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

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

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

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

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

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

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

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

Завіса...

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

LinkedIn

Лучшие комментарии пропустить

Бывают и хуже расклады.
ПМ: есть таска. Маленькая. На пол-дня максимум.
Дев: так нельзя делать. Проблемы будут тут, тут и даже вот тут. Решить правильно займёт 3 дня.
ПМ: мы в спринт не уложимся. Делаем за пол-дня, потом решим правильно.
Следующий спринт.
Дев: там осталась недоделанная таска с прошлого спринта. Ее доделать бы.
ПМ: да ну нах. Работает — и ладно. Тут от нас ещё 3 новых фичи требуют.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Працював переважно в продуктових компаніях без таких дурощів від ПМ-ів, бо рішення швидко чи якійсно приймала команда або CTO коли планували задачі на наступний спринт

Судячи з описаних випадків, проблема в поганому, а то і відсутньому, change management-і. Тактика чи стратегія тут ні до чого

попытка выяснить что нужнее тактика или стратегия — аналог истории про «что было раньше курица или яйцо» )

стратегiя важливiше, а для тактики достатньо притримуватися: «нiч простояти да день продержаться»

Хочу порекомедовать автору обратиться к классике. «Повелитель мух» — поучительная история о лидерах, которые преследуют стратегические цели в ущерб тактическим ;-)
Sad but true...

Ну ви не путайте орган з пальцем, виживання і робота над проектом це дві кардинально разні ситуації в яких я бував. При надзвичайних ситуаціях в преш чергу мають прийматись тактичні рішення, але від цього забувати про стратегічні це вірна смерть. Навіть в цьому романі дітей спасли тому, що бочали дим від вогню. При розробці проектів ситуація зовсім інша. Всьому має бути своє місце і у всьому має бути баланс.

В «Повелителе мух» вопрос выживания не стоял. Фруктов там всем хватало, чтобы не умереть. Конфликт заключался в том, тратить ли силы на то, чтобы поддерживать огонь, который должен был принести спасение (стратегическая цель) или на добывание мяса потому что это вкусно и сытно (тактическая цель). Никакой разницы с проектным менеджментом нет.

«Повелитель мух» так-то не более, чем литературная выдумка, написанная весьма мрачным дядькой. В реальности, в очень похожей ситуации попавшие на необитаемый остров дети вели себя совсем по-другому (это известный исторический случай, который произошёл в 20м веке и имеет документальные свидетельства)

футбольна команда з дітей складалась. Але це було в горах. Єдина ще історія про дітей які потрапили в надзвичайну ситуацію в 20-му столітті, це про дітей в печері яких хотів спасати Ілон Маск. Але то вже було в 21-му столітті

Если «дети» это 18-21 год, то да, из детей...

Нет, история, про которую я говорил, случилась в Африке: www.theguardian.com/...​shipwrecked-for-15-months

как пишет лурк:
Книга (П.М.) является едким стебом над вышедшим лет эдак на сто раньше романом под названием «Коралловый остров» (вплоть до иронического упоминания сабжа спасшим Ральфа офицером). Там детки (примерно с теми же именами) попадают на такой же остров, но живут в гармонии друг с другом и местными. Когда-то считалось классикой, но Голдинг был несогласен, вследствие чего и прикольнулся.
(конец цитаты)

вообще, это забавно что художественное произведение принимается как некое научно достоверное исследование, и применяется как аргумент.

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

вообще, это забавно что художественное произведение принимается как некое научно достоверное исследование, и применяется как аргумент.

Забавно, это когда человек сам придумывает какое-то утверждение, а потом сам же начинает его оспаривать :-)

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

Спасибо. Было интересно почитать. Это, конечно, не Африка, а глубокая Океания: www.google.com/maps/place/Tonga
Пару слов по теме.
1. «Повелитель мух», конечно, не тру-стори, но это не значит, что такого в принципе не может быть, или что в ней нет рационального зерна. Мне кажется, что как раз там очень наглядно показано столкновение лидерских позиций ориентированных на долгосрочную и краткосрочную перспективу и именно с тем финалом, который мы обычно видим в жизни. Популисты, как правило, побеждают реформаторов. Менеджер, который демонстрирует хорошие тактические результаты в ущерб стратегическим, как правило, получит больше поощрения, чем тот, который в итоге добъется большего, но в более отдаленной перспективе.
2. Тру стори имеет слишком много отличий от книги, чтобы опровергать ее. Отличается и возраст и культура. Но самое важное, что здесь маленькая группа изначально друживших между собой подростков, которые сами решились на это путешествие. Тогда как в книге это больщая группа малознакомых детей, оказавшихся на острове случайно. Ну, и, конечно, характеры конкретных участников тоже имеют значение.
3. Единичный случай в такой сложной системе, как группа людей в экстремальных обстоятельствах, в принципе не может быть серьезным доказательством того, что все всегда будет происходить по тому же сценарию.

Поэтому:
1. Тру стори не опровергает историю «Повелителя мух».
2. «Повелить мух» не надо рассматривать как скрипт человеческого или детского поведения в отрыве от взрослых. Как из всего художественного, важно вынести те идеи, которые автор сознательно или неосознанно туда заложил.

Тру стори имеет слишком много отличий от книги, чтобы опровергать ее.
Тру стори не опровергает историю «Повелителя мух».

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

Как из всего художественного, важно вынести те идеи,

художественные произведения направлены прежде всего на чувства
идеи излагаются в другого вида литературе.

автор сознательно или неосознанно туда заложил.

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

результатом же который делает худ произведение классикой, шедевром, будет влияние на нравственность, на флажки «что такое хорошо, а что такое плохо»

а идеи...
идеи у «фрейда», а не у беллетристов :)

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

,
Любое утверждение*, чтобы быть подтвержденным или опровергнутым, должно быть проверено экспериментально. Вообще не важно выдвинул его журналист, писатель, священник или оно было выведено и рассчитано сильнейшим физиком-теоретиком. Сложные закономерности (unknown unknowns) должны проверяться серией экспериментов. Но даже тогда полной уверенности что гипотеза верна, не будет.

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

Это ты сам додумал, я такого не утверждал. Я говорил только о том, что одного случая, тем более с сильно отличающимися исходными данными, недостаточно, чтобы заявлять, что версия «Повелителя Мух» невозможна в реальной жизни.

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

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

художественные произведения направлены прежде всего на чувства

Нет. Художественная литература это не только любовные романы.

результатом же который делает худ произведение классикой, шедевром, будет влияние на нравственность, на флажки «что такое хорошо, а что такое плохо»

Добавь «в моем понимании» после слова «шедевр». Т.к. многие люди назовут шедеврами «Властелин Колец» или «Дюну», при этом эти произведения вряд ли хоть как-то повлияли на нравственность ;-)

* - за исключением аксиом и теорем, имеющих строгое математическое доказательство

Питання виживання якраз стояло. Ви випускаєте їх з вигляду. Коли вони летіли ніхто ще не знав, що вони розіб’ються, і ніхто не знав як буде далі. Що і нормально. Після катастрофи першим ділом мабуть в них стояло питання фрутів яке дуже швидко вирішилось тому, що їх було вдосталь. Я не бачу просто протиріч. В проектному менеджменті також приймаються тактичні рішення, це яскраво видно коли вилазять баги на проді і ніхто тоді не думає про стратегію, і це правильно, і краще зробити як небудь фікс аби робило ніж філософствувати про стратегії. Але в проектному менеджменті ситуації з багами більше винятки ніж звичайний режим роботи. Я веду до того що, в принципі, людям властиво гіперболізувати або недооцінювати проблеми тим чи іншим методом і питання та там же одну функцію написати нафіга нам городити тут якусь нормальну архітектуру це обумвлено тим що люди недооцінюють задач через що в майбутньому вилазять проблеми хоча ніяких надзвичайних ситуацій немає і можна спокійно сісти і подумати над вирішенням задачі.

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

Бывают и хуже расклады.
ПМ: есть таска. Маленькая. На пол-дня максимум.
Дев: так нельзя делать. Проблемы будут тут, тут и даже вот тут. Решить правильно займёт 3 дня.
ПМ: мы в спринт не уложимся. Делаем за пол-дня, потом решим правильно.
Следующий спринт.
Дев: там осталась недоделанная таска с прошлого спринта. Ее доделать бы.
ПМ: да ну нах. Работает — и ладно. Тут от нас ещё 3 новых фичи требуют.

Я просто тут це залишу))

scontent.flwo3-1.fna.fbcdn.net/...​34e47aa7e98d2&oe=5EEE0523

А ваша історія реальна. Якось був в такій ситуації

Абсолютно реальна. Взята из жизненного опыта :)

Насправді ціна фіч в стабільному проекті знижується. Просто масштаби фіч ростуть.

Блін, це геніальна пікча. Шкода не на анг.

ПМ: почему фича не на проде?
QA: еще тестим, уже нашли вот и вот баг
Дев: а я ж говорил
ПМ: это наверное на пограничных случаях? Пропускайте, давайте в прод!

Следующий спринт.
Планирование:
Дев: там осталась ...
Прерывает влетающий ПродактОвнер
Орлы, на проде целых две баги, служба поддержки уже просто копипастит сообщения пользователей!
ПМ: а-а-а, о-о-о
Заходит рук админов
Извините, но мы не можем обновить инфу по ..., потому что вылетает баг
Дев: а я говорил...

Через несколько спринтов:
ПМ: есть таска. Маленькая. На пол-дня максимум.

І після цього всього

ПМ: фіг тобі, а не підняття зарплати — ти баги плодиш!

какой-то токсичный дев однозначно

Бывают

!?!?! Да они постоянно такие расклады!
И если кто-то скажет, что «вот у нас на проекте не так», знайте — они врут.

Это ваше стратегическое мышление хорошо только на собесе, как раскажешь кулстори с практики, так все вау-вау.

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

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

В момент, коли є проблема — не важливо: хто її зробив, чому так погано написано, кого за це шпинькати.
Коли є проблема важливо:
— її потрібно розв’язати?
— які причини привели до проблеми (лише ті причини важливі, які спонукають до розв’язку)?
— які варіанти розв’язку і їх раціональність?

Коли усі це розуміють, то система просто оживає і працює. І люди просто не витрачають час дарма.

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

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

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

Вибачте, але я не зовсім розумію виразу «тактичне рішення».
Бо тактика — це вже певний метод для розв’язку. Який використовують для досягнення мети стратегії. Тобто це означає, що коли приходить проблема, то ви обираєте один з варіантів тактики подолання проблеми. І обрана тактика не може суперечити стратегії. Бо інакше тактика є хибною.
Але думаю, що якщо замінити «тактичне рішення» на щось схоже до «ситуаційний розв’язок» у вашому тексті, то тоді все складно і погоджуюся.
Але це все може бути неправильним розумінням тексту.

І отут я зрозумів, що ПМ прийняв тактичне рішення тобто ситуативне,

Та, можливо я не до кінця правильно висловлююсь. Я якраз про такі ситуативні рішення які в майбутньому вилазять боком.

— Я тільки html форму логіна поправив, а на проекті система бекапів лягла. ©
І це сталось в супер крутого сеньйора який є мега крутим програмістом. Без жартів. В сеньйорів також факапи бувають.

Выглядит так, что факап в этой истории если и был, то раньше: когда систему бэкапов «ключница делала»...

А были бы джуны на проекте, было бы хоть спихнуть на кого ) Вот она, истинная ценность джунов )

В тому випадку ми завжди нили що то стара архітектура і вона г*вно. Тому і конало)

так і було тому всі і зрозумінням поставились і просто поржали)))

Ну ось. Всі ми люди, всі можемо зрозуміти. Давайте просто перестанемо гівнокодити.

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

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

Поэтому с такими ПМ-ами нужно всегда класть на их пожелания и возражения и делать нормальную и правильную архитектуру.

Очень поможет при поиске работы.

Всегда поражался таким людям, на пожелания и возражения кладут, а потом кто виноват? ПМ.

Это называется опыт. Когда пожелания и возражения ПМа принимаются, то в итоге виноват дев остаётся конечно же. Ведь он «не продумал, не предупредил», ведь «ПМ — не тех.специалист».

У всех свой опыт. Но в целом, кто принимает конечное решение, тот и несет ответственность.

В целом, ПМ рассказывает заказчику какие плохие дэвы и всё.

Один відсоток можемо лишити на те що ПМа можна ще переконати) Тут якраз, до речі, люди і писали, що по тій причині, що приходиться затрачати багато енергії на переконання перейшли з лідів в просто деви. Але з досвіду бачу, що це не вирішення ситуації. Бо приходиш на новий проект і часто від тебе хочуть щоб ти вже знав всі тонкощі тійєї старої архітектури яку вони сто років назад писали і щоб ти писав без багів. А коли в тебе падають бекапи то не архітектура вина, а ти бо ти ж крутий сеньйор мав би все врахувати!! І вже ти трішки не настільки крутим стаєш) В випадку з бекапами всі тоді прекрасно розуміли що нові баги зявляються тільки через стару архітектуру, але таке розуміння скорше виняток.

Переубеждать можно, но это просто разве что ради спортивного интереса.

На самом деле ПМу просто безразлична эта вся архитектура, паттерны, у него другие области ответственности, ему это понимать не надо.

Та не всім, є і насправді нормальні. Які знають що якщо зараз нормально не зробити то через пів року їм прийдеться довго виправдовуватись перед клієнтом чому і звідки зявляються так багато нових багів.

Вы думаете, они будут оправдываться? Они скажут, вон девы напедалили говна такие сякие :)

якщо зараз нормально не зробити

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

Но при этом вера в то, что дев действительно сделает «нормально» остается только верой.

Нижче якраз писали про довіру ПМа до девів. Вона повинна бути бо без неї команда вже не команда.

гда на новую фичу другой дев скажет, что предыдущая архитектора отстой

Обовязково скаже! Тоді б не потрібно було такого поняття як рефакторінг. Саме головне що він зможе тільки сидіти і нити, що стара архітектура відстій привносячи ще більше багів.

То просто якість, а ніфіга не тактика і не стратегія. Архітектура може бути гівном, але тоді таски повинні просто робитись довше, бо треба буде більше часу в тому числі на те, щоб впевнитись, що нічого не зламається. А не як у першому прикладі. А як ти не знаєш, як що працює, або щось працює просто напросто не так, як треба (як схоже, у другому прикладі із spooky action at distance), або ти просто забив перевіряти — то приколи будуть і будуть часто. Це, насправді, не про красиво, чи не красиво, це про очікувано, чи неочікувано. Код має поводитись очікувано і не давати зайвих сподівань. І деви, у свою чергу. мають знати, що вони знають, а що вони не знають і не писати те, що вони не знають. А як пишуть — то гарненько перевіряти і іншим казати і радитись із ними. Тоді сюрпризів буде мало.
ПМ хоче тактичне рішення, а не стратегічне — пояснив йому плюси-мінуси, але все одно хоче тактику — гаразд. Потім може йому поясниш, чому через таска буде робиться тиждень, а не півдня. Але із боку дева треба, щоб воно таки нормально працювало через цей тиждень і код не робив неочікуваних речей.

ПМ хоче тактичне рішення, а не стратегічне — пояснив йому плюси-мінуси, але все одно хоче тактику — гаразд.

Вся суть допису. Зазвичай так і трапляється. Тому цей допис адресований сокріше не девам

Це не має вести до купи факапів. Якщо веде — це деви винні, а не ПМ. Хоч у тупого ПМа мабуть і деви такі самі.
І ПМ жеж може бути і правий із своїм тактичним рішенням. Ну я не знаю, в мене не було поганих ПМів, з чимось я був не згоден, але не тотально не згоден.

Це і не веде до купи факапі ні сьогодні, ні завтра, ні навіть після завтра. Це приведе до купи факапів не вас і не цього ПМа який прямав це рішення. Це приведе до купи факапів вже інших людей, які будуть сидіти, дивитись ваш код, який наслоївся купою іншого коду інших девів, і кричати «який довбень це писав??» не розуміючи, що тоді це рішення було правильним. Це якраз і є технічний борг який невпинно росте, завжди, і ви можете повпливати тільки на скорість росту його.

Бачив всякі різні підходи до боротьби з технічним боргом. Навіть були випадки що фічі реалізовувались в два етапи. Перший, писали швидко якнебудь. Другий, рефакторінг.

Так а це значить, що це — дуже успішний проект, якщо він стільки прожив. І для нього, мабуть, було прийнято багато гарних рішень. І захоплення сповільненням тех. боргу — таки може вбити.

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

Я тільки html форму логіна поправив
це сталось в супер крутого сеньйора

Супер крутой сеньор правил хтмл форму логина?

то будь добрий, напиши машину часу
Не можеш?
То не настільки ти і класний

Оценивать профессионализм специалиста по его возможности построить машину времени — это сурово

Так а че сказать хотел?

Супер крутой сеньор правил хтмл форму логина?

Ага, коли на проекті всі сеньйори таким комусь приходиться займатись.

Оценивать профессионализм специалиста по его возможности построить машину времени — это сурово

Насправді, мене дуже вбиває коли мамкині сеньйори починають обговорювати чиюсь стару архітектуру і обсирати її, а через пів години пишуть таке саме

А хотів сказати, що час від часу треба думати не тільки тут і зараз, а інколи і на перед))

на проекті всі сеньйори

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

а через пів години пишуть таке саме

А при чем тут строительство машины времени?

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

Думать никогда не вредно.
Но это напоминает «Крылья, ноги, два хвоста»: «Лучше день потерять, но за час долететь»

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

Насправді дуже крутий, тому що джуна прийшлось запрягати не тільки на форму логіна, а і на інші таски, а потім тицяти його носом і пояснювати чого він ту чи іншу таску зробив не правильно і відповідно тратитичас за який можна самому ту форму підправити. Потім все ж таки взяли одного для експеременту, він два місяці попрацював і звільнився зі словами «сложно і не інтєрєсно».

А при чем тут строительство машины времени?

не вдалий жарт)

пояснювати чого він ту чи іншу таску зробив не правильно

А сеньор не завалил проект поменяв форму логина.... Ну да.

взяли одного для експеременту

Значит плохо отбирали. Нанимай медленно — увольняй быстро.

Любой спец требует затрат на «вхождение в проект». Даже при самой лучше проектной документации.
Но джун стоит в разы дешевле сеньора.
Ну и мотивация сеньора сильно падает, если на него сливать простейший багфиксинг
Как следствие, такой сеньор рано или поздно свинтит с проекта, где ему станет скучно и уныло. Или просто соседи его захантят на +500. Да и банальный «bus-factor» никто не отменял

И тогда без свежей крови на проекте, можно столкнуться с серьезной проблемой — старики уходят, а молодняка, который бы мог «подхватить упавшее знамя» и нет особо. А затыкать «вакансию» сеньора вновь нанятым джуном — ну то такое себе удовольствие

Значит плохо отбирали. Нанимай медленно — увольняй быстро.

Увольняти бистро вони вміють дуже добре. В них не було проблем звільнити в один день два сеньйора по причинам, що один не дотягує по js, а другий хоче багато грошей.

Але насправді для них така система працює і дуже добре. Я їх розумію чому вони не беруть джунів.

два сеньйора
один не дотягує по js

Т.е. они предварительно наняли сеньора, который не дотягивал по js?

Просто привід щоб звільнити))) Не зійшлися поглядами з лідом)))

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

Просто є каста недоторканих) на яких все тримається) Все як і у всіх)

каста недоторканих) на яких все тримається

Грубейшая ошибка менеджмента

Все як і у всіх

Нет

Написал, скомпилил — и в прод!
Нашел новую багу. Нужен патч!
Написал, скомпилил — и в прод!

Романтика!

А у девопсов сейчас тесты в пайплайнах подают...

Написал, скомпилил, тесты завалил © Галя Девелопер

Ну так вот вам аджайл. шо не так? спецификаций нет — развлекайтесь

Та без аджайла как правило не сильно лучше. Процент заваленных проектов не ниже :)

голый аджайл так себе методика. здравый смысл гораздо продуктивнее

голый Эджайл это и есть здравый смысл. Что по-вашему является глупостью в манифесте?

Давай меньше оскорблений и больше по делу. Какие конкретно пункты эджайл манифеста лишены здравого смысла?

еще раз — слепое следование манифесту, созданному под конкретные задачи за 10 дней, во всех сферах разработки ПО — фанатизм. Что конкретно в нем не так — см. проблему топикстартера

Ок, какие пункты agile manifesto подходят только для
«Под конкретные задачи за 10 дней».
Давайте заканчивать демагогию и добавлять конкретику в обсуждение.

А эджайл не про продуктивность — он про predicted delivery.
Продуктивность — это заменить менеджеров и куа на девелоперов. Вот тогда все продуктивно заколосится (нет).
Деливери менеджер не нужен

При всей моей нелюбви к T-shape, иногда кажется что это таки проще, правда планку на такого чувака задирается заметно выше(зарплата и требования к опыту/знаниям) и продать джуна как синьора уже не получится и пачку менеджеров к ним тоже.

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

Ну...ващет...аджайл не значит что спецификаций нет, и/или не должны быть.

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

Просто ты токсичный девелопер, без софт скилов :-)))

146%
надо было носом тыкать софтскиллзово:
www.youtube.com/watch?v=Mi-YLIwkfJs

Мабуть у багатьох так було коли на великих проектах міняєш якийсь невеликий функціонал, а валиться півпроекта

все правильно
регрессии для слабаков
а new feature пусть сами юзеры тестируют. и репортят. нету репорта — нету проблемы мухахахахаха.

Team lead відкриває для себе світ розробки. Правда не дуже зрозумів що конкретно тебе бентежить.

Team lead відкриває для себе світ розробки

Так буває)

Бентежить, що зазвичай в 99% приймаються ситуативні рішення.

Бентежить, що зазвичай в 99% приймаються ситуативні рішення.

Ну так це в житті взагалі в основному так, не тільки в розробці. Але в розробці на відміну від життя придумали цілу низку різних інструментів щоб мінімізувати їхній негативний ефект.

От! я ж і про те, всякі там патерни, підходи до розробки і тд і тп.))) Просто зазвичай коли хтось не технічних чує про це все в нього виникає думка що це довго і затратно. І що один маленький функціонал в одну функцію скоріше, а не оці всі ваші архітектури і паттерни)

Якщо таке

І що один маленький функціонал в одну функцію скоріше

вирішується не техничним персоналом, значить у вас немає технічного персоналу взагалі. Тоді терпи, що ще тобі порадити.

Он и есть тот персонал и его задача доказать вышестоящим почему нужно делать так и потратить на это столько времени, а не вот так и потратить вот столько времени и еще много разного объяснить.

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

Да. На это я указал ниже ему:

поймешь через лет 5-7, когда опыта поднаберешься.

Он, как и положено подростку, обиделся.

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

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

От, і я про те, але інколи буває, що оце доказати займає за багато енерігії

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

От через це інколи і підгорає.

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

З.Ы. И да, я не был «менеджером-передастом».

да, со временем оказалось что работа «просто» программиста лучше всего :)

Это стандартная разработка. По другому «со стратегиями» не бывает.
Так что расслабься и делай то, что грит менеджрен и не забывай вовремя менять работу на +500 (не успеешь, самому придется в своем говнокоде ковыряться).

Якраз не хотілось би міняти проект бо в своєму говнокоді не можеш розібратись. Якраз і хочеться щоб «зі стратегіями» було хоча б трішечки більше.

Это «подростковые» фантазии про «мир во всем мире». Сколько я где работал, везде клепался «тактический» говнокод, что на галерах, что в продуктах, что в местных, что в импортных.
Да, всем хочется «мира во всем мире», но все делают все ради войн — это суть людей.

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

Поэтому ты фантазировать можешь, никто не запрещает, но придется адаптироваться к обществу и делать то, что требуют.
И из этого вытекает: Не спорить лишнего с начальством, говнокодить, как все и менять конторы вовремя на +500, как все.

А когда начало сыпаться у них всё, я слинял, через 8 месяцев они обанкротились, их купила другая контора и продолжает клепать те же роботы. Завалили не из-за «моего» софта, а из-за того, который в работе роботом управлял — там ситуация еще хуже была. Завалили большой заказ от Интела на 300-ки.
Новая контора выкинула софт для прода и написала его с нуля, заново. Тот что я саппортил еще много лет продолжали юзать в том же режиме падучести.

Я в своєму дописі не пропагую «мир у всьому світі».

... то гірше рішення буде правильнішим

Я працював на софті який стоїть в лікарнях. І коли при зміні хтмл форми впала ціла система бекапів софта то всі відразу зрозуміли що в якийсь момент щось пішло не так. І успішно почали паралельний рефакторінг з додаванням нових фіч. У вашому ж випадку на костиляння затрачається багато ресурсів і те що вашу ідею було відхилено це якраз знову ж було прийнято тактичне рішення, і воно більш ресусно затратне, але якщо в бізнесп є гроші на це то чому б і ні))

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

Я в своєму дописі не пропагую «мир у всьому світі».

А это

стратегічні рішення

?

А с остальным? Я тебе попытался объяснить, но видно поспешил. Сам поймешь через лет 5-7, когда опыта поднаберешься.

А ви значить пропонуєте
«На фіг це всьо, фігаш в одну фунцію!»

Я правильно вас зрозумів?

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

*пішов писати допис про те що треба нафіг звільнити як мінімум всіх архітекторів бо менеджар сказав все в одну функцію!*

Bogdan Parkhomenko Team lead — так ты ж и есть тот менаджар.

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

не у всіх питаннях

Я так розумію якщо PM визначає такі стратегічні рішення розвитку проекту як

в одну функцію

твоя зона відповідальності це рішення по йменуванню змінних?

Ну якщо ви самі на проекті вирішуєте який функціонал додавати сьогодні, а який завтра, що рефактори, а що ні то я вам заздрю)

В смысле? Это всегда согласование работы и сроков с выше и нижестоящими.

Ваша роль, це дати оцінку фічам\фіксам, пояснити чому на цю фічу\фікс потрібно стільки-то часу, де більше ризиків в реалізації фіч\фіксів і вміти відстояти позицію кращого рішення на вашу думку.

Роль ПМ-а в даному випадку, це визначити фічі\фікси, бізнес велью яких найвищий і на основі вашої оцінки витрат ресурсів та ризиків розставити пріорітети для розробки.

Я так розумію, у вас виникає колізія прийняття рішень — це вирішується донесенням описаної вище думки про розподіл обов’язків.

Так я світчер)

яжемать!

Подписаться на комментарии