![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Если на клетке слона написано «буйвол»
Прекрасная история на работе. У нас над проектом работает 2 отдела. Один из дирекции инвестиций (DI), другой из страховой дирекции (DAP). Код проекта хранится в SVN, депозиторий назвали di — просто потому, что в тот момент я работал в DI, не подумал.
В этой же DI есть внутренний аудитор, с которым лично у меня не получалось работать. Мне вообще сложно с людьми, которые сначала задают вопрос, чтобы узнать что-то для себя новое, слушают, ответа не понимают, но зато начинают после этого пытаться тебя же исправлять. Не понимая половины слов даже в собственных фразах. Начальнику я на него жаловался, но это же мой начальник, а не его. Мой начальник решил забить («сделай так, чтобы он больше мне не писал»), через некоторое время я сменил дирекцию (не из-за этого, но это был однозначно дополнительный бонус для перехода в DAP) и подумал, что можно об этом персонаже забыть.
Но недавно наш герой увидел название депозитория и потребовал, чтобы к нему имели доступ только сотрудники DI. Почему? Потому что депозиторий называется di. В этом месте нельзя не вспомнить анекдот про пограничника и Fiat Uno, только у нас это не анекдот. Начальник отдела DI взял под козырёк, отослал мейл в DSI (информатики, управляют правами доступа), и на следующий день у нас не было доступа (собственно, откуда мы и узнали о внутренней жизни соседней дирекции).
Собрались все члены проекта, начали искать решение. Я предложил переименовать репозиторий :-) Но в силу других причин этого решили не делать. Начальник отдела DI предложил сделать два репозитория и назначить ответственного за ручную синхронизацию между ними (я не шучу). К счастью, этот вариант тоже не приняли.
Решили в итоге перекроить права доступа так, чтобы работники из DI имели доступ ко всему репозиторию, а работники DAP — только к части его. Сделали новые спецификации, отослали в DSI. Через день у нас снова были права, на выделенный нам кусочек. При этом работники DI потеряли все права целиком. Ещё день ушёл на то, чтобы починить права DI. Сколько денег / человеко-часов мы потеряли из-за этого анекдота, я не берусь посчитать.
В этой же DI есть внутренний аудитор, с которым лично у меня не получалось работать. Мне вообще сложно с людьми, которые сначала задают вопрос, чтобы узнать что-то для себя новое, слушают, ответа не понимают, но зато начинают после этого пытаться тебя же исправлять. Не понимая половины слов даже в собственных фразах. Начальнику я на него жаловался, но это же мой начальник, а не его. Мой начальник решил забить («сделай так, чтобы он больше мне не писал»), через некоторое время я сменил дирекцию (не из-за этого, но это был однозначно дополнительный бонус для перехода в DAP) и подумал, что можно об этом персонаже забыть.
Но недавно наш герой увидел название депозитория и потребовал, чтобы к нему имели доступ только сотрудники DI. Почему? Потому что депозиторий называется di. В этом месте нельзя не вспомнить анекдот про пограничника и Fiat Uno, только у нас это не анекдот. Начальник отдела DI взял под козырёк, отослал мейл в DSI (информатики, управляют правами доступа), и на следующий день у нас не было доступа (собственно, откуда мы и узнали о внутренней жизни соседней дирекции).
Собрались все члены проекта, начали искать решение. Я предложил переименовать репозиторий :-) Но в силу других причин этого решили не делать. Начальник отдела DI предложил сделать два репозитория и назначить ответственного за ручную синхронизацию между ними (я не шучу). К счастью, этот вариант тоже не приняли.
Решили в итоге перекроить права доступа так, чтобы работники из DI имели доступ ко всему репозиторию, а работники DAP — только к части его. Сделали новые спецификации, отослали в DSI. Через день у нас снова были права, на выделенный нам кусочек. При этом работники DI потеряли все права целиком. Ещё день ушёл на то, чтобы починить права DI. Сколько денег / человеко-часов мы потеряли из-за этого анекдота, я не берусь посчитать.
no subject
Я действительно советую поддерживать правильные имена репозиториев, и менять имена так же буднично, как делают рефакторинг. Чтобы имена соответствовали. А не хранили какую-то историю. В этом смысле я скорее как тот пограничник.
no subject
no subject
Так ведь если человек пытается тебя исправлять, то это помогает понять, чего именно этот человек не понимает. И, соответственно, позволяет помочь этому человеку понять то, что он не понял.
Разве это плохо?
no subject
no subject
Почему именно в этом случае попытка исправить - очень плохо?
no subject
no subject
no subject
no subject
А то, что ты описываешь насчёт замены компьютеров или хранения данных в облаке - вопрос не управленческий, а финансовый: есть деньги - платишь провайдеру (информатика аутсорсится сплошь и рядом) и получаешь вот это вот как сервис. Проблема в том, что в жизни нам чаще попадаются не "правильные управленцы", а вот именно что "настоящие". Мне кажется, что это связано прежде всего с тем, что для корпоративной карьеры нужны человеческие качества, в значительной степени антагонистичные нужным для "идеального управленца". Хотя всякое бывает, к счастью!
Вот я тебе пример из банковской жизни: DSI принял решение перевести нечто на микросервисы-клауд-ноэскюэль в клауде. Наняли десяток девелопёров (некоторые из них при этом - очень толковые) и они начали нафигачивать требуемуе. А Маша проверяет, правильный ли результат получается. И вот, один из девелопёров (самый умный) спрашивает её: "а как ты узнаёшь, правильные ли у нас результат?" Ну, она ему и отвечает: "а я сперва разбираюсь, что там надо сделать, пишу соответствующий эскюэль запрос над исходной базой" и сравниваю - то же ли самое у вас получилось. если нет - значит, где-то у вас ошибка". Ну, бедный парень аж побледнел: "а что мы тут все делаем вообще тогда?" и через неделю уволился, сказав, что в банки он больше ни ногой. Вот это оно самое и есть!
no subject
Зачем переводить работающее приложение на микросервисы?
> "а я сперва разбираюсь, что там надо сделать, пишу соответствующий эскюэль запрос над исходной базой" и сравниваю - то же ли самое у вас получилось. если нет - значит, где-то у вас ошибка".
А как ещё проверить можно?
Читая старый и новый код?
> Ну, бедный парень аж побледнел: "а что мы тут все делаем вообще тогда?"
Они пишут новый код.
Почему он побледнел?
> и через неделю уволился, сказав, что в банки он больше ни ногой
Почему нет?
no subject
В идеале, тестирование свеженаписанной программы должно включать сравнение её выхода с заведомо корректным результатом. Весь вопрос в том, откуда брать этот самый заведомо корректный результат. Как правило, он вычисляется и перепроверяется эспертом (экспертами), это трудоёмкий и дорогой процесс. Препаолагается, что программа нужна для того, чтобы облегчить (ускорить, удешевить) получение результата. А в нашем случае выясняется, что правильный результат получается более-менее одной левой, сильно быстрее, чем производимой программой.
они пишут не просто новый код, а новый бессмысленный код: команда специалистов в течение условных двух недель производит результат (с высокими требованиями к инфраструктуре), который не-программист получает в течение десяти-двадцати минут, при этом не нагружая инфраструктуру (и производительность во втором случае сильно выше). Ну а теперь представьте себе молодого человека (справедливо) считающего себя хорошим профессионалом, видящего, что он производит совершенно бессмысленную работу. Это крайне унизительно, поверьте. Соответственно, его нежеление работать в подобных организациях, мне кажется, довольно понятно.
no subject
Вероятно, так и было.
Только это - во вред владельцам компании. Но это проблема владельцев компании, а не бюрократов, пилящих корпоративный бюджет.
> В идеале, тестирование свеженаписанной программы должно включать сравнение её выхода с заведомо корректным результатом. Весь вопрос в том, откуда брать этот самый заведомо корректный результат.
> Как правило, он вычисляется и перепроверяется эспертом (экспертами), это трудоёмкий и дорогой процесс.
Зачем вычислять эталонный результат экспертами вручную, если эти эксперты уже написали программу (legacy), которую можно использовать для проверки?
> Препаолагается, что программа нужна для того, чтобы облегчить (ускорить, удешевить) получение результата.
Так ведь цель - не облегчить получение результата, а распил бюджета и престиж в бюрократическом руководстве.
Разве все эти консультанты раньше этого не знали?
> А в нашем случае выясняется, что правильный результат получается более-менее одной левой, сильно быстрее, чем производимой программой.
Что мешало консультантам самим использовать этот более простой подход при тестировании?
> они пишут не просто новый код, а новый бессмысленный код: команда специалистов в течение условных двух недель производит результат (с высокими требованиями к инфраструктуре), который не-программист получает в течение десяти-двадцати минут, при этом не нагружая инфраструктуру (и производительность во втором случае сильно выше). Ну а теперь представьте себе молодого человека (справедливо) считающего себя хорошим профессионалом, видящего, что он производит совершенно бессмысленную работу.
Что в этом страшного?
Ошиблись. В следующий раз будут знать как сделать быстрее.
Тем более, что им за этот раз - тоже хорошо заплатят.
> Это крайне унизительно, поверьте.
Я тоже участвовал в переписывании работающего legacy приложения - на более современное (по тем временам).
Причём новое приложение, в целом, так и не заработало.
Я сделал для себя выводы. Но унизительным свой опыт - совершенно не считаю.
Тем более, что мне заплатили за приобретение этого опыта.
> Соответственно, его нежеление работать в подобных организациях, мне кажется, довольно понятно.
Мне - не совсем понятно.
no subject
Консультантам мешало то, что их наняли не на получение результата вообще, а на его получение с использованием определёного тулсета (право на принятие решения и компетенции - разнесены, о чём я и писал в начале этой ветки). Я не знаю, как объяснить, что в этом страшного и унизительного, - для древних греков, к пример, это было само собой разумеющимся, что они и зафиксировали в истории про Сизифа. В современном мире это тоже явление давно понятное широким массам, см известную работу Graeber про bullshit jobs.
no subject
Если им удалось написать полезную работающую программу, то почему вы не считаете их экспертами?
> во-вторых, правила вычисления результата периодически меняются (в соответствии с изменениями реглементации), отсюда и возникает необходимость модификаций.
Так ведь эти модификации в legacy программе делали, верно?
> Консультантам мешало то, что их наняли не на получение результата вообще, а на его получение с использованием определёного тулсета
Так ведь повышение статуса бюрократа, оплатившего эту работу - это и есть результат.
Я правильно понимаю, что этот программист не считал повышение статуса его клиента - достойным результатом?
> Я не знаю, как объяснить, что в этом страшного и унизительного, - для древних греков, к пример, это было само собой разумеющимся, что они и зафиксировали в истории про Сизифа.
Сизифов труд - мучителен, но совсем необязательно унизителен:
===
https://www.perplexity.ai/search/schitaetsia-li-sizifov-trud-un-674CMxDDSTC4GVmzNxbeMQ#0
В древнегреческой мифологии Сизиф был наказан богами за хитрость и обман вечным выполнением бессмысленной задачи — вкатыванием камня на гору, который неизменно скатывался вниз. Это наказание символизирует бесконечный и бесплодный труд, который воспринимается как форма мучения, но не обязательно унижения.
===
А переписывание программы - совсем не бесконечное. Через какое-то время переписывание программы прекращается.
no subject
Какое-то время, разумеется, это делали в старой программе, а потом решили её переписать на другом тулсете.
А вот дальше впечатление, что вы прикалываетесь резко усиливается: оплачивает работу разумеется не бюрократ, а организация, на которую он работает. А вы думали, что это не так?? Стало быть, достойным результатом для наёмного специалиста может быть какая-то польза для организации, которая его наняла, так? Тогда выходит, что повышение статуса бюрократа (во вред нанимающей организации - он разбазаривает её средства) - это что-то очень далёкое от "достойного результата". Или вы считаете иначе? Гм.
Самым мучительным в труде Сизифа является унижение, тут ваш источник откровенно не врубается.
no subject
Так эксперты же были частью команды.
Иначе откуда бы программисты узнали, какие именно "финансовые правила и установления" имплементировать?
> Какое-то время, разумеется, это делали в старой программе, а потом решили её переписать на другом тулсете.
Вы предполагаете, что legacy программу перестали обновлять как только решили эту программу переписать на другом тулсете?
Перестать обновлять legacy программу - было бы очень рисковано, потому что вероятность успешного переписывания программы на новом тулсете - не высокая.
> А вот дальше впечатление, что вы прикалываетесь
Это ошибочное впечатление.
Я не прикалываюсь.
> оплачивает работу разумеется не бюрократ, а организация, на которую он работает
Решение об оплате - принимает бюрократ (и в этом смысле "оплачивает").
С точки зрения получения денег - имеет значение, в первую очередь, кто принимает решение, а не из чьего кармана взяты эти деньги.
> Стало быть, достойным результатом для наёмного специалиста может быть какая-то польза для организации, которая его наняла, так?
Может быть и польза для организации.
Но важнее -- польза для бюрократа, принявшего решение.
Важнее всего - польза для самих программистов-контракторов: чему они научились, что поможет решать проблемы их будущих клиентов.
> Тогда выходит, что повышение статуса бюрократа (во вред нанимающей организации - он разбазаривает её средства) - это что-то очень далёкое от "достойного результата". Или вы считаете иначе?
Да, я считаю иначе.
Действительно, принести пользу нанимающей организации полезно. Но это не основная цель с точки зрения контрактора.
Организация может быть очень большой.
Проблема распределения пользы внутри нанимающей организации - это ответственность самой организации.
Если нанимающая организация решила делегировать решение бюрократу - то, с точки зрения контрактора - бюрократ и представляет эту организацию. И именно на точку зрения этого бюрократа, в первую очередь, и следует полагаться при принятии решения.
Если бюрократ делегирует часть своих полномочий кому-то ещё (например, бизнес аналитику или пользователям внутри организации) - контакторам полезно учитывать и их мнения тоже.
> Самым мучительным в труде Сизифа является унижение
В глазах каких именно окружающих труд Сизифа снижает чувство собственного достоинства?
===
https://www.perplexity.ai/search/chto-vyzyvaet-chuvstvo-unizhen-ilS46ux1RyqptsxvtbqAMA#0
Чувство унижения возникает в результате действий или ситуаций, которые снижают чувство собственного достоинства человека и его уважение в глазах окружающих.
===
no subject