Мне кажется, начать нужно с понимания, а что же такое фирма, в которой есть такие отношения. Фирма существует для того, чтобы владелец получал прибыль. Фирма генерирует прибыль путем создания ценности клиентам с помощью наемного труда. Все ключевые свойства и ограничения вытекают из этого тезиса. Фирме работники нужны только ради их функции — помогать компании с помощью их экспертизы и труда создавать выручку. Но для того, чтобы эти отношения были стабильными и выгодными для фирмы, нельзя игнорировать то, что сотрудник — человек и личность. Поэтому мы будем заботиться в некоторой степени его моральным духом, здоровьем, настроением, удовлетворенностью работой и многими другими вещами, которые вы указали в статье. Фирма заинтересована в поддержании корпоративной культуры только в той степени, в которой это ей выгодно для получения прибыли.
Из статьи же можно сделать ложный вывод, будто компания почему-то должна сама по себе создавать культуру и т.п. Это — лишь способ достижения основной цели, не более того. Отсюда вытекает очень приземленное понимание того, должен ли тут кто-то кому-то и в каком количестве.
чётко разделяет вертикаль: есть топы, есть менеджеры среднего звена, есть рядовые сотрудники. И вовсе не обязательно топам слушать, чем живут сотрудники, а сотрудникам просить у топов каких-то мотивированных решений. Каждый делает свою работу на своём месте, компания живёт своей жизнью. Однако именно при таком раскладе копятся причины для типичных корпоративных конфликтов
Из самой экономической роли фирмы вытекает подобная структура. Есть факторы производства (труд), а есть управленческая верхушка (владелец фирмы и его помощники). Есть некоторая напряженность в фирме как раз из-за непонимания основных отношений в фирме: «почему топы столько получают, я же больше для фирмы делаю», «менеджер меня должен уважать» и другие вещи, которые вы затронули в статье. Это понятно с человеческой точки зрения, и дальновидный владелец фирмы заинтересован в том, чтобы это не вытекало в открытые конфликты, чтобы система была «сбалансированной». Но попытка сказать «на самом деле нет никаких топов, мы все равны, все всё заслужили, посмотрите» — это просто обман. Реально существующие отношения заменяются приторной толерантной картинкой «все люди братья» (как у гугла был слоган — don't be evil). Богатая компания может себе позволить развлекаться и поддерживать обман довольно долго. Но когда работник вдруг сталкивается с актуальным ограничением (например, для работников одни негласные правила, а для менеджмента — другие), то розовые очки разбиваются, и наступает разочарование и непринятие.
Опять-таки, какие-то владельцы фирм могут думать о себе в другом ключе, такие безусловно существуют. Но если они не считают, что фирма существует ради прибыли, то они проигрывают конкурентную гонку и выбывают из игры.
Фаворит — это сотрудник, который влияет на управленческие и кадровые решения благодаря своему статусу, опыту или же просто высокому расположению.
Владелец бизнеса решает свои собственные задачи. Часть его помощников занимает свое положение не из-за своей экспертизы, а по причине доверия. Почему он должен делегировать ключевые для него вопросы кому-то, кто пусть и хороший специалист, но к кому нет личного доверия?
С мыслью статьи «если вы полностью игнорируете людей и забываете о том, что они — личности, то у фирмы будут проблемы» я согласен. С отсутствием мотивировки, почему это важно для фирмы — нет. Простите, если вышло длинно.
Возможно это и нормальная ситуация (это индивидуально), но назвать ее здоровой и ожидаемой – это уже слишком.
Рост напряжения будет возникать между любыми двумя личностями, которые имеют общие интересы и взаимодействуют. Это касается романтических отношений, бизнеса, участия в спортивной команде или чего-то иного. Даже если прямо сейчас вы вроде бы нашли точки соприкосновения и согласия, завтра ситуация изменится, и вы на эту ситуацию будете смотреть уже немного по-разному. Это различие будет появляться просто потому что вы — разные личности. Вы можете находиться в состоянии слияния некоторое время, и из-за этого вам может казаться, что «мы — единое целое, мы имеем идентичные интересы, мы смотрим на бизнес одинаково», но это проходит. Вопрос как раз в том, что вы будете делать в ситуации различающихся точек зрения, будете ли вы это различие признавать, будете ли вы о нем как-то заявлять или будете терпеть, будете ли вы пытаться нащупать новый компромисс, как вы это будете проживать и т.п. От этого и будет зависеть, будете ли вы конфликт называть «нормальными разногласиями взрослых людей, которые решаются в рабочем порядке» или «я ему верил, а он мне всю карьеру испортил».
Закрепите его на бумаге и все перечисленные проблемы не будут вызывать ощущения напряжения!
Это проблема другого порядка. То, как вы будете себя вести на эмоциональном уровне, не зависит от того, что вы юридически что-то закрепите.
Очень легко всё в голове свести к одному понятному фактору, благодарить в успехах и винить в неудачах только его. К сожалению в жизни всё не так просто.
Забавно, что с точки зрения ответственности это как раз логично — в многокомандной компании крайним должен быть руководитель и только он. Человек вне команды, увидев, что член команды Петя выкатил говнокод в прод, может захотеть сказать «какой плохой Петя, такой ужасный код пишет». Но он не знает, какую цель ставил его руководитель и как распределена ответственность в команде! Может, этот сервис еще не обрабатывает пользователей, может это проверка «сработают ли алерты», может Петя герой, который написал на коленке сервис за день и спас запуск продукта, или что-то ещё.
Т.е. все помои по умолчанию должны лететь в тимлида, а он уже должен разбираться, виноват ли Петя, а если виноват, то в чем именно. Если они летят в исполнителя, то возникает очень мощная негативная мотивация «я не виноват, а меня обвиняют, в следующий раз я лучше вообще светиться не буду».
Примерно как ментейнер — код может вообще не писать, но за общее качество кода проекта отвечает.
Мне кажется, тут происходит подмена понятий. Под тезисом «авторитарный руководитель хорош в кризис» в моем понимании имеется ввиду «у нас тут аврал, бери лопату, копай прямо щас, некогда объяснять». Т.е. это хорошо подходит для того, чтобы взять в охапку ресурсы и бросить их туда, где горит. При этом эффективность будет в целом невысокой, т.к. не учитываются индивидуальные отличия, локальные особенности и т.п. Для огромного периода 14 лет такой режим точно не подходит, запала не хватит, там явно было что-то иное. Может в эпле тоже было что-то авторитарное, но явно не уровня «Петька, бросай всё н@$%#, там объект разнесло».
В статье как раз в качестве примера приводятся кранчи — нам нужно поднажать, т.к. сроки горят. И это известно, что точечные кранчи могут быть эффективными, но постоянно в таком режиме работать невозможно.
В моем тезисе не было слова «только», там были слова «значительная часть». Мой тезис был и про западные страны (вообще трудно рассматривать глобализованный рынок труда разработчиков без своего центра), и про джунов. Мидл/джун — условное деление, в разных фирмах классификация сильно отличается. Чем менее опытен специалист, тем более он заменим, и тем работодатель более привиредлив к нему. Чем опытнее сотрудник, тем он ценнее для компании и тем сложнее его заменить, и тем работодатель будет больше бегать и охотиться за такими сотрудниками. Это классический рынок — в ком нуждаются, тот и диктует условия.
Можно конечно не смотреть на рынок в целом, а только на эпсилон окрестность вокруг кого-то. Тогда конечно можно найти точку, в которой HR-ы будут только такие :) Но мой первый комментарий был именно про рынок в целом, а не про локальные случаи уровня «негосударственные коммерческие организации», «Россия», «Java-сеньоры» и т.п.
Возможно, напишу непопулярную мысль. Далеко не все IT-шники принадлежат рынку работника, значительная часть рынка — рынок работодателя. Т.е. не вы 10 раз думаете, пойти ли мне в эту компанию, а компания 10 раз думает, а нужны ли вы ей. Раз такие компании существуют большое количество времени и приносят прибыль, значит их выбор правильный, он подтверждается реальностью. А значит такие компании будут успешно использовать подходы к найму айтишников не из FAANG, а как к винтикам, к которым нет никакого восхищения, и в случае чего мнящий о себе винтик будет быстро (ибо процесс налажен) заменен на подходящий.
Разработчику это может не нравится, и если вы живете на рынке работника, то замечательно. Проходите мимо, вы ищете другую компания, а компания ищет другого работника. Но если почему-то все компании вокруг именно такие, а гуглы с амазонами на меня не обращают внимания, то может быть все же дело во мне, и пора снизить планку, снять розовые очки и начать обращать внимание на то, что же реально требуется компаниям.
Люди увольняются не из-за плохой работы, а из-за плохих руководителей. Исследование Герцберга показывает, что вторым по значимости негативным фактором, влияющим на мотивацию, является плохое руководство. Первый – политика компании и бюрократия, что на самом деле является следствием плохого руководства.
По ссылке статья платная. По тексту можно предположить, что опросы показывают, что уходящие с текущего места работы люди винят в своих проблемах, во-первых, руководителей, во-вторых, политику компании и бюрократию, что бы это ни значило. Это не то же самое, что и «в компании плохое руководство».
Может быть у человека слишком завышенные ожидания, он не соглашается с этим и винит во всем несправедливого руководителя. Если спросить мнение коллег, то человек действительно плохо работает. В этом случае можно сказать, что проблема на уровне плохой обратной связи, и что в этом есть ответственность руководства, но это уже совсем другой вывод.
Во-вторых, среди технических специалистов много людей, которые вообще не понимают проблемы управления и причинно-следственные связи в этой области. Специалисты вообще по своей природе склонны жить «в информационном пузыре». Они видят проблемы только в моменте, не видят принимаемые решения руководства (или их отсутствие). Если плохо налажен процесс разработки, то проблема не в том, что не настроен CI, нет системы обмена знанием, а в том, что на код ревью ко мне слишком сильно придираются. Проблема не в том, что команда 80% временем занята неприоритетными задачами, а в том, что злой бизнес не дает времени на увлекательный рефакторинг. Если я не понимаю, как устроено управление в компании, как принимаются решения, как распространяется информация, какие причинно-следственные связи, я буду склонен искать причину непосредственно в том предмете/в той ситуации, в которой меня отчитали или в которой я почувствовал дискомфорт.
Во-первых, «графический интерфейс пользователя» намекает на то, что с UI работает конечный пользователь-человек, который с помощью компьютера решает свою собственную проблему. Его не интересует, как эта чертова машина работает внутри, хоть там под капотом живут волшебные гномики и исполняют мои приказы. Упрощение UI для пользователя — это решение проблемы использования компьютера, а не программирования.
Во-вторых, из деятельности программирования можно вычленить огромное число этапов, которые не являются созданием алгоритмов. Тут и построение лейаутов, и прототипирование UI, и собственно дизайн, и визуализация данных, и многое другое. То, что из сложного программирования смогли вычленить гораздо более простые этапы и решить их более простыми способами с меньшими требованиями к работнику, это замечательно. Но собственно программирование при этом не перестало быть «текстовым».
В-третьих, есть большое число сторон программирования, которые бывает полезно визуализировать. У нас есть и UML-диаграммы разных видов, и флеймграфы, и doxygen с извлечением разнообразной информации из исходного кода. Но это всё суть производные программирования, дополнения и продолжения, а не замены. Они играют роль не замены программирования, а в некотором смысле моделирования, построения модели — мы берем сложный алгоритм, выделяем в нем какие-то важные для обсуждения вопросы (например, связи между классами или модулями), отбрасываем несущественные детали и работаем с моделью. Модель помогает думать о «реальности» (т.е. программе), но не заменяет собой реальность.
Работа с g_data1, g_data2, g_data3 действительно происходит неатомарно. Но работа с этими данными заканчивается строго до того (happens before), как происходит атомарное изменение флага. Поэтому пофиг, как именно происходит взаимодействие с g_data*, параллельных обращений к ним нет. Это верно для ограниченного примера, где среди читателей есть только пример с
if (g_flag) f(g_data1, g_data2, g_data3);
Если бы было чтение или запись в эти переменные до проверки g_flag, то действительно была бы гонка, а с т.з. стандарта языка — UB.
ТЗ может поменяться многократно, думаю Вы с этим тоже сталкивались. Это значит, что интерфейсу с самого начала уделили мало внимания.
Т.е. если бы заранее подумали бы лучше, то ТЗ не пришлось бы менять. Agile же говорит, что вы в принципе априорно не владете всей полнотой информации, чтобы написать хороший ТЗ. Какой бы ТЗ не написали, в результате разработки вы получите новую информацию, которой ТЗ противоречит, и вам придется переписывать ТЗ.
Правда, в «просто потребляйте информацию» есть огромная проблема. Она заключается в том, что многие ресурсы в каких-то вопросах дают разные ответы.
Важно не потреблять информацию, а уметь ее переваривать. Если я прочитал 100 книг, но не понял, как это знание применить, как описанные модели соотносятся с другими моделями, в каких ситуациях правила работают, когда какие принципы имеет смысл применять, то я являюсь лишь архивом информации, а не специалистом. Это отличает просто начитанного человека от думающего и умеющего.
В одной и той же ситуации разные специалисты применили диаметрально противоположные решения. При этом у первого результат на 10% попугаев выше. Что это значит, что его решение всегда на 10% лучше? Или что он лучше владеет инструментом? Или наоборот, этот разброс в рамках погрешности, и оба инструмента имеют право на жизнь? Или что у него организация труда в команде плохо устроена, а инструменты для этой задачи все плюс-минус одинаковые?
В июне я перенес коронавирус и больничный позволил прочесть пару лишних книг.
Переболевшие друзья говорят, что в коронавирус очень сильно снижается концентрация внимания, невозможно делать что-то, что требует повышенной концентрации и сложно чему-либо учиться. У вас это было не так? Или эти книги — легкое чтиво, с которым можно просто ознакомиться в любом состоянии сознания?
Это и не предлагается. Предлагается уйти от подхода «сначала продумай всё». Проблема в том, что заранее спроектировать все детали сложной системы не получится, слишком большой уровень неизвестности и изменчивости. То, что инженер сконструировал априорно, либо будет устаревшим на момент реализации, либо вообще не будет соотноситься с реальностью. Для уменьшения уровня неизвестности нужен эксперимент, контакт с реальностью, альфа-версия, как хотите называйте. Поэтому в разработке ПО у нас вместе с водопадом есть agile, одним из принципом которого является «работающий продукт важнее исчерпывающей документации».
То, что вы говорите про «сначала всё продумай» является частью мышления в представлении изготовления продукта, в котором неизвестность маленькая, в нем всё можно просчитать, вычислить и предусмотреть заранее. В этом случае действительно эффективнее будет упорядочить работу по модели водопада и как можно раньше просчитать всё, что можно просчитать (в т.ч. описать интерфейсы, контракты, инварианты и т.п.). Если вы знаете, что в ваших условиях есть большая доля неизвестности и изменчивости, априорные вычисления будут просто неверны, у вас в приниципе недостаточно информации для принятия решения.
Уже третий день после статьи рефлексирую насчет темы неизвестности, изменчивости, реакции на события и конвейера в производстве. Некоторые разрозненные факты складываются в очень простую и четкую картинку. Спасибо за перевод.
Описание процесса разительно отличается от подавляющего большинства статей, описаний и обсуждений про скрам. 99% информации про скрам — это по сути карго-культ. Вот тебе правила — выполняй. Вот тебе принципы — следуй им. Следовать принципам хорошо, не следовать им — плохо. Возможно дело в коммерциализации скрама? Если навыки владения фреймворком продаются как товар, то создание карго-культа — это способ создать рынок для товара.
Про зоны ответственности. В тексте этого не написано, как у вас устроены команды? Это 30 равноправных команд, каждая из которых занимается разработкой определенной части продукта? Или у вас есть инфраструктурные команды, которые не взаимодействуют с заказчиками, не решают проблемы бизнеса, не релизят продуктовые сервисы и сайты? Почему было выбрано такое решение? Или его никто не выбирал, оно сложилось, как получилось?
Про обучение. Судя по тексту, обмен опытом у вас происходит в основном через митапы (не суть важно, удаленные или очные). Но это же огромное дублирование усилий — невозможно попасть на прошедший митап второй раз, невозможно попасть на митап, на котором меня не было. Можно проводить запись митапов, но видеоинформацию очень дорого анализировать, искать по ней, копипастить и т.п. Почему вы не систематизируете информацию на внутренней вики или в ином текстовом виде? Были какие-то организационные проблемы, почему так не сделано?
Из-за того, что мы не обеспечили совместимость технологий, нам пришлось отказаться от команды, которая работала на других технологиях.
Звучит очень странно, что вы оказались перед выбором «либо продолжать использовать технологию Б, либо на мороз». Т.е. вы будто уже начинаете разработку по формуле «если этот проект не получится, то сотрудников перевести на другой проект не получится».
Я правильно понимаю, что разработка любого проекта у вас происходит в полной свободе выбора технологий со стороны команды? Кто хочет, тот выбирает Java, кто хочет — PHP, кто хочет — Rust. На стек технологий ограничений со стороны СТО нет?
Лень — это лишь топливо. Качество костылей будет зависеть от дальновидности человека. Если сисадмин ленивый и у него большой горизонт планирования, то он не будет делать костыль, который завтра придется переписывать.
Другое дело, что админ при тушении «пожара» может вставить плохо сделанный костыль, который будет потом сложно вытащить. Но это уже не вопрос лени, а вопрос готовности к инцидентам.
Из статьи же можно сделать ложный вывод, будто компания почему-то должна сама по себе создавать культуру и т.п. Это — лишь способ достижения основной цели, не более того. Отсюда вытекает очень приземленное понимание того, должен ли тут кто-то кому-то и в каком количестве.
Из самой экономической роли фирмы вытекает подобная структура. Есть факторы производства (труд), а есть управленческая верхушка (владелец фирмы и его помощники). Есть некоторая напряженность в фирме как раз из-за непонимания основных отношений в фирме: «почему топы столько получают, я же больше для фирмы делаю», «менеджер меня должен уважать» и другие вещи, которые вы затронули в статье. Это понятно с человеческой точки зрения, и дальновидный владелец фирмы заинтересован в том, чтобы это не вытекало в открытые конфликты, чтобы система была «сбалансированной». Но попытка сказать «на самом деле нет никаких топов, мы все равны, все всё заслужили, посмотрите» — это просто обман. Реально существующие отношения заменяются приторной толерантной картинкой «все люди братья» (как у гугла был слоган — don't be evil). Богатая компания может себе позволить развлекаться и поддерживать обман довольно долго. Но когда работник вдруг сталкивается с актуальным ограничением (например, для работников одни негласные правила, а для менеджмента — другие), то розовые очки разбиваются, и наступает разочарование и непринятие.
Опять-таки, какие-то владельцы фирм могут думать о себе в другом ключе, такие безусловно существуют. Но если они не считают, что фирма существует ради прибыли, то они проигрывают конкурентную гонку и выбывают из игры.
Владелец бизнеса решает свои собственные задачи. Часть его помощников занимает свое положение не из-за своей экспертизы, а по причине доверия. Почему он должен делегировать ключевые для него вопросы кому-то, кто пусть и хороший специалист, но к кому нет личного доверия?
С мыслью статьи «если вы полностью игнорируете людей и забываете о том, что они — личности, то у фирмы будут проблемы» я согласен. С отсутствием мотивировки, почему это важно для фирмы — нет. Простите, если вышло длинно.
Рост напряжения будет возникать между любыми двумя личностями, которые имеют общие интересы и взаимодействуют. Это касается романтических отношений, бизнеса, участия в спортивной команде или чего-то иного. Даже если прямо сейчас вы вроде бы нашли точки соприкосновения и согласия, завтра ситуация изменится, и вы на эту ситуацию будете смотреть уже немного по-разному. Это различие будет появляться просто потому что вы — разные личности. Вы можете находиться в состоянии слияния некоторое время, и из-за этого вам может казаться, что «мы — единое целое, мы имеем идентичные интересы, мы смотрим на бизнес одинаково», но это проходит. Вопрос как раз в том, что вы будете делать в ситуации различающихся точек зрения, будете ли вы это различие признавать, будете ли вы о нем как-то заявлять или будете терпеть, будете ли вы пытаться нащупать новый компромисс, как вы это будете проживать и т.п. От этого и будет зависеть, будете ли вы конфликт называть «нормальными разногласиями взрослых людей, которые решаются в рабочем порядке» или «я ему верил, а он мне всю карьеру испортил».
Это проблема другого порядка. То, как вы будете себя вести на эмоциональном уровне, не зависит от того, что вы юридически что-то закрепите.
Забавно, что с точки зрения ответственности это как раз логично — в многокомандной компании крайним должен быть руководитель и только он. Человек вне команды, увидев, что член команды Петя выкатил говнокод в прод, может захотеть сказать «какой плохой Петя, такой ужасный код пишет». Но он не знает, какую цель ставил его руководитель и как распределена ответственность в команде! Может, этот сервис еще не обрабатывает пользователей, может это проверка «сработают ли алерты», может Петя герой, который написал на коленке сервис за день и спас запуск продукта, или что-то ещё.
Т.е. все помои по умолчанию должны лететь в тимлида, а он уже должен разбираться, виноват ли Петя, а если виноват, то в чем именно. Если они летят в исполнителя, то возникает очень мощная негативная мотивация «я не виноват, а меня обвиняют, в следующий раз я лучше вообще светиться не буду».
Примерно как ментейнер — код может вообще не писать, но за общее качество кода проекта отвечает.
В статье как раз в качестве примера приводятся кранчи — нам нужно поднажать, т.к. сроки горят. И это известно, что точечные кранчи могут быть эффективными, но постоянно в таком режиме работать невозможно.
Можно конечно не смотреть на рынок в целом, а только на эпсилон окрестность вокруг кого-то. Тогда конечно можно найти точку, в которой HR-ы будут только такие :) Но мой первый комментарий был именно про рынок в целом, а не про локальные случаи уровня «негосударственные коммерческие организации», «Россия», «Java-сеньоры» и т.п.
Как это опровергает тезис про то, что существенная часть рынка так устроена?
Разработчику это может не нравится, и если вы живете на рынке работника, то замечательно. Проходите мимо, вы ищете другую компания, а компания ищет другого работника. Но если почему-то все компании вокруг именно такие, а гуглы с амазонами на меня не обращают внимания, то может быть все же дело во мне, и пора снизить планку, снять розовые очки и начать обращать внимание на то, что же реально требуется компаниям.
По ссылке статья платная. По тексту можно предположить, что опросы показывают, что уходящие с текущего места работы люди винят в своих проблемах, во-первых, руководителей, во-вторых, политику компании и бюрократию, что бы это ни значило. Это не то же самое, что и «в компании плохое руководство».
Может быть у человека слишком завышенные ожидания, он не соглашается с этим и винит во всем несправедливого руководителя. Если спросить мнение коллег, то человек действительно плохо работает. В этом случае можно сказать, что проблема на уровне плохой обратной связи, и что в этом есть ответственность руководства, но это уже совсем другой вывод.
Во-вторых, среди технических специалистов много людей, которые вообще не понимают проблемы управления и причинно-следственные связи в этой области. Специалисты вообще по своей природе склонны жить «в информационном пузыре». Они видят проблемы только в моменте, не видят принимаемые решения руководства (или их отсутствие). Если плохо налажен процесс разработки, то проблема не в том, что не настроен CI, нет системы обмена знанием, а в том, что на код ревью ко мне слишком сильно придираются. Проблема не в том, что команда 80% временем занята неприоритетными задачами, а в том, что злой бизнес не дает времени на увлекательный рефакторинг. Если я не понимаю, как устроено управление в компании, как принимаются решения, как распространяется информация, какие причинно-следственные связи, я буду склонен искать причину непосредственно в том предмете/в той ситуации, в которой меня отчитали или в которой я почувствовал дискомфорт.
Во-первых, «графический интерфейс пользователя» намекает на то, что с UI работает конечный пользователь-человек, который с помощью компьютера решает свою собственную проблему. Его не интересует, как эта чертова машина работает внутри, хоть там под капотом живут волшебные гномики и исполняют мои приказы. Упрощение UI для пользователя — это решение проблемы использования компьютера, а не программирования.
Во-вторых, из деятельности программирования можно вычленить огромное число этапов, которые не являются созданием алгоритмов. Тут и построение лейаутов, и прототипирование UI, и собственно дизайн, и визуализация данных, и многое другое. То, что из сложного программирования смогли вычленить гораздо более простые этапы и решить их более простыми способами с меньшими требованиями к работнику, это замечательно. Но собственно программирование при этом не перестало быть «текстовым».
В-третьих, есть большое число сторон программирования, которые бывает полезно визуализировать. У нас есть и UML-диаграммы разных видов, и флеймграфы, и doxygen с извлечением разнообразной информации из исходного кода. Но это всё суть производные программирования, дополнения и продолжения, а не замены. Они играют роль не замены программирования, а в некотором смысле моделирования, построения модели — мы берем сложный алгоритм, выделяем в нем какие-то важные для обсуждения вопросы (например, связи между классами или модулями), отбрасываем несущественные детали и работаем с моделью. Модель помогает думать о «реальности» (т.е. программе), но не заменяет собой реальность.
Если бы было чтение или запись в эти переменные до проверки g_flag, то действительно была бы гонка, а с т.з. стандарта языка — UB.
Вы это сказали тут:
Т.е. если бы заранее подумали бы лучше, то ТЗ не пришлось бы менять. Agile же говорит, что вы в принципе априорно не владете всей полнотой информации, чтобы написать хороший ТЗ. Какой бы ТЗ не написали, в результате разработки вы получите новую информацию, которой ТЗ противоречит, и вам придется переписывать ТЗ.
Важно не потреблять информацию, а уметь ее переваривать. Если я прочитал 100 книг, но не понял, как это знание применить, как описанные модели соотносятся с другими моделями, в каких ситуациях правила работают, когда какие принципы имеет смысл применять, то я являюсь лишь архивом информации, а не специалистом. Это отличает просто начитанного человека от думающего и умеющего.
В одной и той же ситуации разные специалисты применили диаметрально противоположные решения. При этом у первого результат на 10% попугаев выше. Что это значит, что его решение всегда на 10% лучше? Или что он лучше владеет инструментом? Или наоборот, этот разброс в рамках погрешности, и оба инструмента имеют право на жизнь? Или что у него организация труда в команде плохо устроена, а инструменты для этой задачи все плюс-минус одинаковые?
Переболевшие друзья говорят, что в коронавирус очень сильно снижается концентрация внимания, невозможно делать что-то, что требует повышенной концентрации и сложно чему-либо учиться. У вас это было не так? Или эти книги — легкое чтиво, с которым можно просто ознакомиться в любом состоянии сознания?
Это и не предлагается. Предлагается уйти от подхода «сначала продумай всё». Проблема в том, что заранее спроектировать все детали сложной системы не получится, слишком большой уровень неизвестности и изменчивости. То, что инженер сконструировал априорно, либо будет устаревшим на момент реализации, либо вообще не будет соотноситься с реальностью. Для уменьшения уровня неизвестности нужен эксперимент, контакт с реальностью, альфа-версия, как хотите называйте. Поэтому в разработке ПО у нас вместе с водопадом есть agile, одним из принципом которого является «работающий продукт важнее исчерпывающей документации».
То, что вы говорите про «сначала всё продумай» является частью мышления в представлении изготовления продукта, в котором неизвестность маленькая, в нем всё можно просчитать, вычислить и предусмотреть заранее. В этом случае действительно эффективнее будет упорядочить работу по модели водопада и как можно раньше просчитать всё, что можно просчитать (в т.ч. описать интерфейсы, контракты, инварианты и т.п.). Если вы знаете, что в ваших условиях есть большая доля неизвестности и изменчивости, априорные вычисления будут просто неверны, у вас в приниципе недостаточно информации для принятия решения.
Описание процесса разительно отличается от подавляющего большинства статей, описаний и обсуждений про скрам. 99% информации про скрам — это по сути карго-культ. Вот тебе правила — выполняй. Вот тебе принципы — следуй им. Следовать принципам хорошо, не следовать им — плохо. Возможно дело в коммерциализации скрама? Если навыки владения фреймворком продаются как товар, то создание карго-культа — это способ создать рынок для товара.
Про обучение. Судя по тексту, обмен опытом у вас происходит в основном через митапы (не суть важно, удаленные или очные). Но это же огромное дублирование усилий — невозможно попасть на прошедший митап второй раз, невозможно попасть на митап, на котором меня не было. Можно проводить запись митапов, но видеоинформацию очень дорого анализировать, искать по ней, копипастить и т.п. Почему вы не систематизируете информацию на внутренней вики или в ином текстовом виде? Были какие-то организационные проблемы, почему так не сделано?
Звучит очень странно, что вы оказались перед выбором «либо продолжать использовать технологию Б, либо на мороз». Т.е. вы будто уже начинаете разработку по формуле «если этот проект не получится, то сотрудников перевести на другой проект не получится».
Я правильно понимаю, что разработка любого проекта у вас происходит в полной свободе выбора технологий со стороны команды? Кто хочет, тот выбирает Java, кто хочет — PHP, кто хочет — Rust. На стек технологий ограничений со стороны СТО нет?
Другое дело, что админ при тушении «пожара» может вставить плохо сделанный костыль, который будет потом сложно вытащить. Но это уже не вопрос лени, а вопрос готовности к инцидентам.