Про кластера... У нас они не использовались в продакшене. Мы разрабатывали десктопное приложение. Кластера нужны были для поддержки разработки. В основном чтобы тесты гонять. Сотни машин, для которых приходилось поддерживать много самописного софта. Сейчас такое решение можно иметь "из коробки".
Дисклаймер... Считаю, что дискуссия про сложность разработки находится в стороне от дискуссии о желании инженерами открывать для себя новые горизонты. Но про сложность разработки поговорить всё равно интересно :)
Итак, про сложность разработки (ну и диплоя в частности). Тут, я думаю, важно сравнивать конкретные вещи, которые при этом действительно сравнимы. То есть сравнивать "яблоки с яблоками", а не уходить в абстрактные материи или обобщения. Учитывая всё это, у меня есть следующие соображения...
1) Для сравнения можно брать совсем уж чёткие категории. Например, "разработка десктопных приложений 20 лет назад и сейчас". На мой взгляд, стало значительно проще. (Детализировать не буду, но если интересует именно такое конкретное сравнение, то готов подискутировать). Но такие сравнения на уровне прямо одинаковых категорий сделать можно не всегда. Поэтому есть другой вариант
2) Можно сравнивать на уровне сложности реализации конкретных требований к софту. Например, взять требования "возможность деплоить новую версию каждый день + наличие неограниченного масштабирования". Можно ли было такое реализовать 20 лет назад? Можно... С огромным количеством денег и прочих ресурсов - можно было... Но по-настоящему мы дозрели до этого не так давно. Сейчас такого можно добиться с уровнем затрат, который по меркам 20-летней давности кажется копеечным. Да, нужны какие-то навыки и умения. Но если сравнивать яблоки с яблоками, то выглядит как огромный прогресс и упрощение. А смысла сравнивать дистрибуцию десктопных приложений и облачный деплоймент не очень много... Важно прийти к равнозначным категориям
3) Даже когда выбраны правильные категории, иногда важно смотреть на все грани разработки софта одновременно, ибо где-то убыло, а где-то прибыло. Допустим, мы сравниваем две оптимальные реализации какого-то требования 20 лет назад и сейчас (слово "оптимальный" зависит от конкретных критериев оптимальности, но это не принципиально сейчас :)). Допустим, 20 лет назад оптимально было делать десктопное приложение, а сейчас - облачное решение. Если мы сравниваем такие реализации, то здесь не только про деплоймент надо говорить. 20 лет назад такого слова никто не знал :) Но зато знали, что такое защита кода от реверс-инжиниринга, одновременная поддержка кучи разных версий (лично я не хочу больше такого ужаса :)), распространение лицензионных ключей, защита бинаря от взлома, совместимость библиотек на машине клиента и ещё дофига всего... То есть где-то убыло, а где-то прибыло. И важно рассматривать всё в совокупности. Лично для меня уже только сложности с поддержкой кучи разных версий софта перевешивают любые сложности облачного деплоймента
4) Важно отличать порог входа от поддержки энтерпрайзных решений и не сравнивать одно с другим. Например, с тех пор как в амазоновскую лямбду стало возможным положить контейнер, порог входа в деплоймент бесконечно масштабируемых облачных сервисов снизился до уровня плинтуса. Сейчас можно запустить сервис любой сложности в облаке, вообще не зная, что такое Кубер. И при этом иметь неограниченное масштабирование и ещё кучу всего. Но ясно, что это стоит денег и каких-то уступок в производительности... А если мы выходим на уровень энтерпрайза, то вот тут начинается: экономия бабок, прогрев инфраструктуры перед пиковыми скачками нагрузки, регионализация сервисов и пр... Однако это не то состояние, в которое мы попадаем одним прыжком сразу с уровня входа. Если рассматривать именно уровень входа, то на мой взгляд, он радикально снижается для всех граней разработки софта. А если говорить про уровень энтерпрайза, то здесь важно смотреть на второй пункт: учитывать не только сложность реализации, а сложность в пересчёте на то, какие плюшки она приносит :)
Ведь у бизнесов нет такого критерия успешности как "благополучие и комфорт сотрудников". Несмотря на то, что все крупные компании декларируют очень благие и светлые цели, типа "сделать мир лучше", все мы знаем, что критерий успешности бизнеса в капиталистическом мире только один - прибыль :) Собственно, под этим углом и надо смотреть. Ну, точнее, сам-то я считаю, что не только под этим, но предположим на минутку, что мы все здесь прожжёные капиталисты.
Как вы верно подозреваете, ни одна из косвенно упомянутых мной компаний не развалилась. Вообще, чтобы транснациональная корпорация или просто очень крупная компания перестала существовать, нужно очень сильно постараться. Во-первых, у них очень сильный задел. И даже если они начинают ну ооочень сильно косячить, то всё равно могут очень долго оставаться на плаву. Как говорит один мой знакомый топ-менеджер, "стоят на плечах великих". Когда он так говорит, то имеет в виду, что даже если компанией руководят полные раздолбаи, то прочный фуднамент, когда-то заложенный отцами-основателями-инноваторами позволит ещё долго раздолбайствовать.
Вторая причина устойчивости - значимость для экономики. Кризисную компанию могут взять под госуправление (как произошло с Интелом) или даже в неё могут начать инвестировать конкуренты (как опять же произошло с тем же самым Интелом и НВидией). На всякий случай, оговорюсь, что не считаю, будто в Интеле было плохо именно с корпоративной культурой. Просто привожу его как пример кризисной компании, которой ну никак не дают совсем утонуть.
Ну и в-третьих, серьёзные встряски, которые получает компания, доходя до кризиса, вероятно, могут приводить к серьёзным заменам в менеджменте, что потенциально может привести к оздоровлению компании. Впрочем, оздоровление - это, как мне кажется, очень сложный сценарий в случае больших компаний. Ибо если прогнила именно культура, то это затрагивает всю компанию целиком. И даже если радикально поменять менеджмент - основная масса всё равно продолжит работать по-старому. Это сценарий, который мы очень часто наблюдаем в разных сферах (особенно в сфере функционирования разных государств).
Итак... Что же случилось с косвенно упомянутыми мною компаниями, если говорить про бабки?.. Вот смотрю на график акций компании, у которой, на мой взгляд, были самые выдающиеся проблемы с корпоративной культурой. Сейчас цена акций находится на уровне 2017 года (при том, что допэмиссий не было). И эта цена в 4 раза ниже исторического максимума. Всё это следствие плохой прибыли. Гнилая корпоративная культура сильно сказывается на инновациях (об этом я чуть больше сказал в первой статье на тему корпоративной культуры), а без инноваций прибыль будет так себе (если вообще будет).
Далее смотрю на вторую по гнилости компанию в моём анти-рейтинге. С ней всё сложнее. Из всех взятых мной за анти-пример компаний она единственная является российской. По ней нет публичных данных. Однако я подозреваю, что прибыль стала только больше. Причём думаю, что значительно. Но там много нюансов :) Во-первых, компания превратилась в огромный холдинг. И не потому, что выросла до этих размеров естественным образом (к сожалению, не могу изложить здесь нюансы). Во-вторых, рынок, на котором работает компания, не является конкурентным. Строго говоря, не является рынком (опять же не могу говорить здесь подробнее). В-третьих, отдельные компании ходлинга могут иметь вполне себе неплохое независимое управление. Я вполне это допускаю.
Так что если резюмировать, в самой стрёмной, с точки зрения культуры, и при этом открытой для анализа компании всё закономерно: ожидаемое снижение прибыли, причём значительное. Во второй по стрёмности компании, но закрытой для анализа, скорее всего, значительное увеличение прибыли, однако со множеством оговорок и нерыночных факторов.
Добрый день! Спасибо за интерес! Если вдруг захотите, поделиться своим мнением, то не стесняйтесь :) Думаю, здесь многим будет интересно. Сам я всегда рад услышать альтернативное мнение
С одной стороны, постоянно меняются реалии: появляются новое железо (например, графические ускорители), облака, контейнеры и пр. Но с другой стороны, постоянно появляется и улучшается софт, чтобы управлять всем этим зоопарком.
Когда я начинал работать, у нас все тестовые фреймворки были самописные. И софт для управления кластерами железа тоже был самописный.
То, что раньше необходимо было пилить руками, сейчас часто даётся из коробки. На мой взгляд, порог входа в разработку - в любые её грани - не увеличивается, а уменьшается. В некоторых случаях - до нуля. Сейчас с помощью нейросетей можно иногда "разрабатывать" софт "под ключ", не зная ничего, кроме естественного языка.
Я бы сказал, что погружение в другую сферу во все времена зависело и продолжает зависеть только от желания и мотивации. Даже если порог входа в новую сферу действительно высокий (имеется в виду, технически, а не эмоционально, допустим), то всё равно никто не мешает хотя бы начать копать в нужном направлении.
При этом речь, конечно же, не идёт о том, чтобы профессионала в какой-то области резко заменять новичком. Например, если речь идёт о деплойменте устоявшихся энерпрайзных геораспределёных решений, то тут новичок с кондачка не разберётся. Скорее, речь о том, чтобы в принципе в некоторых ситуациях браться за нехарактерные - но посильные - для себя задачи.
Ой, плюшек много разных бывает. Чай, сахар и молоко - одни из самых простых. Ещё бывает зерновой кофе и машины, которые его заваривают; корпоративный мерч; ДМС; компенсация расходов на спорт; компенсация расходов на проезд и питание; возможность купить продукцию компании с огромной скидкой (но в ограниченных количествах, конечно же) и т.п.
Теперь немного философии не тему "сколько по времени может вестить экспериментальная разработка"...
Да сколько угодно! Есть множество причин, которые влияют на сроки.
1) Продукт может быть объективно технологически сложным. Например, космическая ракета или микропроцессор. Здесь на эспериментирования могут уйти многие годы. Одна очень известная микропроцессорная корпорация годами вела экспериментальные разработки, которые иногда полностью сворачивались 2) Продукт может опираться на технологию, которая пока ещё не дозрела. Например, пока нейронки не стали уверенно распознавать изображения, разработки, которые полагались на технологию распознавания, могли топтаться на месте в попытках доработать другие методы. Но как только нейронки взлетели - сразу много ещё чего взлетело. Что касается конкретно моего опыта, то могу сказать про системы хранения данных. Бывало, что обещана какая-то "магическая" железка, на базе которой начинается софтверная разработка. Но аппаратчики могут переносить сроки появления этой железки, менять концепцию железки или вообще никогда её не родить 3) Компания уже может иметь какой-то супер-успешный продукт, который приносит кучу денег. Поэтому новые разработки может вести вяло и небольшими силами 4) Основной продукт компании может быть прикрыт сильными патентами. И поэтому компания не заинтересована сильно продвигать экспериментальные решения до того, как начнёт истекать срок патента 5) Иногда компания может решить, что слишком сильно педалировать новые разработки невыгодно или даже опасно. Например, в прошлом или позапрошлом году одна фармкомпания была оштрафована на миллиарды долларов, потому что было показано, что у неё были доказательства эффективности нового продукта, но она не выводила его на рынок, потому что успешно продавала старый, который был защищён патентом. Соответственно, компания ждала, когда истечет патент, чтобы вывести новый продукт. Компанию обвинили во множестве смертей, которые могли бы не случиться, если бы более эффективное лекарство вывели на рынок сразу. Так что если бы компания затягивала с экспериментальным продуктом, то исков удалось бы избежать. Это, на мой вкус, звучит кощунственно, но фармкомпании могут думать иначе. Там каждый новый продукт требуетс вложений миллиардов баксов. Поэтому компании стремятся максимально отработать инвестиции в старый продукт, прежде чем выводить новый
В общем, мотивов или объективных сложностей может быть много... Это неисчепаемая тема...
Я здесь не стал вдаваться в полную историю того продукта. Полный жизненный цикл там, конечно же, был довольно сложный. Более того, первые наработки по тому продукту появились за 8 лет до релиза, но затем на 5 с лишним лет разработка была заморожена по определённым причинам, которые я не могу здесь озвучивать (но кое-что скажу ниже, в следующем комментарии...) В общем, там и concept proof был, и иследование потребительского спроса, и многочисленные изменения в концепции, и отработка отдельных технологических этапов... Но это всё совсем другая история, которая увела бы нас в сторону от основной. Главное, что разработка на любых этапах велась в отрыве от финального вИдения продукта даже за 6 месяцев до релиза. Более того, финального вИдения вообще не существовало. Да, там идеально были отработаны отдельные технологические операции (которые по большей части осуществлялись софтом). Но вопросы интеграции, вписывания в существующую инфраструктуру, взаимодействия с клиентом и т.д. и т.п. не были проработаны совсем.
Конкретно я считаю, что разработка даже concept-proof версий не должна происходить совсем уж в вакууме. Всегда должно быть какое-то вИдение финальной архитектуры. Да, оно может быть неполным, может изменяться хоть каждый день, но оно должно быть. И разработка на любом шаге (возможно, кроме самого-самого начального) должна соответствовать общей архитектурной канве. Там могут быть отсутствующие "куски", могут быть упрощенные, но общая архитектура должна выдерживаться (даже если она периодически изменяется). И вопросы связывания отдельных "блоков" решения в общую картину должны прорабатываться так же, как и сами блоки/операции по отдельности. Именно в такой парадигме мне посчастливилось всегда работать вплоть до описанного случая.
Ого! Даже такое бывает? Если учесть, что нейросетки в целом "склонны" льстить, подчёркивать правоту и мотивировать, то вырисовывается так себе картинка... Это если руководитель опирается исключительно на "мнение" сетки или ставит его выше всего... В целом, думаю, нет ничего зазорного спросить что-то у нейронки. Но надо держать в уме, что нейронка может льстить, ошибаться, что нужно посоветоваться с экспертами-людьми и что если есть расхождения, то неплохо бы запросить аргументацию и у тех, и у других :)
Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин: 1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях 2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату 3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Про кластера... У нас они не использовались в продакшене. Мы разрабатывали десктопное приложение. Кластера нужны были для поддержки разработки. В основном чтобы тесты гонять. Сотни машин, для которых приходилось поддерживать много самописного софта. Сейчас такое решение можно иметь "из коробки".
Дисклаймер... Считаю, что дискуссия про сложность разработки находится в стороне от дискуссии о желании инженерами открывать для себя новые горизонты. Но про сложность разработки поговорить всё равно интересно :)
Итак, про сложность разработки (ну и диплоя в частности). Тут, я думаю, важно сравнивать конкретные вещи, которые при этом действительно сравнимы. То есть сравнивать "яблоки с яблоками", а не уходить в абстрактные материи или обобщения. Учитывая всё это, у меня есть следующие соображения...
1) Для сравнения можно брать совсем уж чёткие категории. Например, "разработка десктопных приложений 20 лет назад и сейчас". На мой взгляд, стало значительно проще. (Детализировать не буду, но если интересует именно такое конкретное сравнение, то готов подискутировать). Но такие сравнения на уровне прямо одинаковых категорий сделать можно не всегда. Поэтому есть другой вариант
2) Можно сравнивать на уровне сложности реализации конкретных требований к софту. Например, взять требования "возможность деплоить новую версию каждый день + наличие неограниченного масштабирования". Можно ли было такое реализовать 20 лет назад? Можно... С огромным количеством денег и прочих ресурсов - можно было... Но по-настоящему мы дозрели до этого не так давно. Сейчас такого можно добиться с уровнем затрат, который по меркам 20-летней давности кажется копеечным. Да, нужны какие-то навыки и умения. Но если сравнивать яблоки с яблоками, то выглядит как огромный прогресс и упрощение. А смысла сравнивать дистрибуцию десктопных приложений и облачный деплоймент не очень много... Важно прийти к равнозначным категориям
3) Даже когда выбраны правильные категории, иногда важно смотреть на все грани разработки софта одновременно, ибо где-то убыло, а где-то прибыло. Допустим, мы сравниваем две оптимальные реализации какого-то требования 20 лет назад и сейчас (слово "оптимальный" зависит от конкретных критериев оптимальности, но это не принципиально сейчас :)). Допустим, 20 лет назад оптимально было делать десктопное приложение, а сейчас - облачное решение. Если мы сравниваем такие реализации, то здесь не только про деплоймент надо говорить. 20 лет назад такого слова никто не знал :) Но зато знали, что такое защита кода от реверс-инжиниринга, одновременная поддержка кучи разных версий (лично я не хочу больше такого ужаса :)), распространение лицензионных ключей, защита бинаря от взлома, совместимость библиотек на машине клиента и ещё дофига всего... То есть где-то убыло, а где-то прибыло. И важно рассматривать всё в совокупности. Лично для меня уже только сложности с поддержкой кучи разных версий софта перевешивают любые сложности облачного деплоймента
4) Важно отличать порог входа от поддержки энтерпрайзных решений и не сравнивать одно с другим. Например, с тех пор как в амазоновскую лямбду стало возможным положить контейнер, порог входа в деплоймент бесконечно масштабируемых облачных сервисов снизился до уровня плинтуса. Сейчас можно запустить сервис любой сложности в облаке, вообще не зная, что такое Кубер. И при этом иметь неограниченное масштабирование и ещё кучу всего. Но ясно, что это стоит денег и каких-то уступок в производительности...
А если мы выходим на уровень энтерпрайза, то вот тут начинается: экономия бабок, прогрев инфраструктуры перед пиковыми скачками нагрузки, регионализация сервисов и пр... Однако это не то состояние, в которое мы попадаем одним прыжком сразу с уровня входа. Если рассматривать именно уровень входа, то на мой взгляд, он радикально снижается для всех граней разработки софта. А если говорить про уровень энтерпрайза, то здесь важно смотреть на второй пункт: учитывать не только сложность реализации, а сложность в пересчёте на то, какие плюшки она приносит :)
Очень справедливый вопрос :)
Ведь у бизнесов нет такого критерия успешности как "благополучие и комфорт сотрудников". Несмотря на то, что все крупные компании декларируют очень благие и светлые цели, типа "сделать мир лучше", все мы знаем, что критерий успешности бизнеса в капиталистическом мире только один - прибыль :) Собственно, под этим углом и надо смотреть. Ну, точнее, сам-то я считаю, что не только под этим, но предположим на минутку, что мы все здесь прожжёные капиталисты.
Как вы верно подозреваете, ни одна из косвенно упомянутых мной компаний не развалилась.
Вообще, чтобы транснациональная корпорация или просто очень крупная компания перестала существовать, нужно очень сильно постараться. Во-первых, у них очень сильный задел. И даже если они начинают ну ооочень сильно косячить, то всё равно могут очень долго оставаться на плаву. Как говорит один мой знакомый топ-менеджер, "стоят на плечах великих". Когда он так говорит, то имеет в виду, что даже если компанией руководят полные раздолбаи, то прочный фуднамент, когда-то заложенный отцами-основателями-инноваторами позволит ещё долго раздолбайствовать.
Вторая причина устойчивости - значимость для экономики. Кризисную компанию могут взять под госуправление (как произошло с Интелом) или даже в неё могут начать инвестировать конкуренты (как опять же произошло с тем же самым Интелом и НВидией). На всякий случай, оговорюсь, что не считаю, будто в Интеле было плохо именно с корпоративной культурой. Просто привожу его как пример кризисной компании, которой ну никак не дают совсем утонуть.
Ну и в-третьих, серьёзные встряски, которые получает компания, доходя до кризиса, вероятно, могут приводить к серьёзным заменам в менеджменте, что потенциально может привести к оздоровлению компании. Впрочем, оздоровление - это, как мне кажется, очень сложный сценарий в случае больших компаний. Ибо если прогнила именно культура, то это затрагивает всю компанию целиком. И даже если радикально поменять менеджмент - основная масса всё равно продолжит работать по-старому. Это сценарий, который мы очень часто наблюдаем в разных сферах (особенно в сфере функционирования разных государств).
Итак... Что же случилось с косвенно упомянутыми мною компаниями, если говорить про бабки?.. Вот смотрю на график акций компании, у которой, на мой взгляд, были самые выдающиеся проблемы с корпоративной культурой. Сейчас цена акций находится на уровне 2017 года (при том, что допэмиссий не было). И эта цена в 4 раза ниже исторического максимума. Всё это следствие плохой прибыли. Гнилая корпоративная культура сильно сказывается на инновациях (об этом я чуть больше сказал в первой статье на тему корпоративной культуры), а без инноваций прибыль будет так себе (если вообще будет).
Далее смотрю на вторую по гнилости компанию в моём анти-рейтинге. С ней всё сложнее. Из всех взятых мной за анти-пример компаний она единственная является российской. По ней нет публичных данных. Однако я подозреваю, что прибыль стала только больше. Причём думаю, что значительно. Но там много нюансов :) Во-первых, компания превратилась в огромный холдинг. И не потому, что выросла до этих размеров естественным образом (к сожалению, не могу изложить здесь нюансы). Во-вторых, рынок, на котором работает компания, не является конкурентным. Строго говоря, не является рынком (опять же не могу говорить здесь подробнее). В-третьих, отдельные компании ходлинга могут иметь вполне себе неплохое независимое управление. Я вполне это допускаю.
Так что если резюмировать, в самой стрёмной, с точки зрения культуры, и при этом открытой для анализа компании всё закономерно: ожидаемое снижение прибыли, причём значительное. Во второй по стрёмности компании, но закрытой для анализа, скорее всего, значительное увеличение прибыли, однако со множеством оговорок и нерыночных факторов.
Добрый день! Спасибо за интерес!
Если вдруг захотите, поделиться своим мнением, то не стесняйтесь :) Думаю, здесь многим будет интересно. Сам я всегда рад услышать альтернативное мнение
Пожалуй, не соглашусь с основным посылом.
С одной стороны, постоянно меняются реалии: появляются новое железо (например, графические ускорители), облака, контейнеры и пр. Но с другой стороны, постоянно появляется и улучшается софт, чтобы управлять всем этим зоопарком.
Когда я начинал работать, у нас все тестовые фреймворки были самописные. И софт для управления кластерами железа тоже был самописный.
То, что раньше необходимо было пилить руками, сейчас часто даётся из коробки. На мой взгляд, порог входа в разработку - в любые её грани - не увеличивается, а уменьшается. В некоторых случаях - до нуля. Сейчас с помощью нейросетей можно иногда "разрабатывать" софт "под ключ", не зная ничего, кроме естественного языка.
Я бы сказал, что погружение в другую сферу во все времена зависело и продолжает зависеть только от желания и мотивации. Даже если порог входа в новую сферу действительно высокий (имеется в виду, технически, а не эмоционально, допустим), то всё равно никто не мешает хотя бы начать копать в нужном направлении.
При этом речь, конечно же, не идёт о том, чтобы профессионала в какой-то области резко заменять новичком. Например, если речь идёт о деплойменте устоявшихся энерпрайзных геораспределёных решений, то тут новичок с кондачка не разберётся. Скорее, речь о том, чтобы в принципе в некоторых ситуациях браться за нехарактерные - но посильные - для себя задачи.
Ой, плюшек много разных бывает. Чай, сахар и молоко - одни из самых простых. Ещё бывает зерновой кофе и машины, которые его заваривают; корпоративный мерч; ДМС; компенсация расходов на спорт; компенсация расходов на проезд и питание; возможность купить продукцию компании с огромной скидкой (но в ограниченных количествах, конечно же) и т.п.
Полностью согласен
Теперь немного философии не тему "сколько по времени может вестить экспериментальная разработка"...
Да сколько угодно! Есть множество причин, которые влияют на сроки.
1) Продукт может быть объективно технологически сложным. Например, космическая ракета или микропроцессор. Здесь на эспериментирования могут уйти многие годы. Одна очень известная микропроцессорная корпорация годами вела экспериментальные разработки, которые иногда полностью сворачивались
2) Продукт может опираться на технологию, которая пока ещё не дозрела. Например, пока нейронки не стали уверенно распознавать изображения, разработки, которые полагались на технологию распознавания, могли топтаться на месте в попытках доработать другие методы. Но как только нейронки взлетели - сразу много ещё чего взлетело. Что касается конкретно моего опыта, то могу сказать про системы хранения данных. Бывало, что обещана какая-то "магическая" железка, на базе которой начинается софтверная разработка. Но аппаратчики могут переносить сроки появления этой железки, менять концепцию железки или вообще никогда её не родить
3) Компания уже может иметь какой-то супер-успешный продукт, который приносит кучу денег. Поэтому новые разработки может вести вяло и небольшими силами
4) Основной продукт компании может быть прикрыт сильными патентами. И поэтому компания не заинтересована сильно продвигать экспериментальные решения до того, как начнёт истекать срок патента
5) Иногда компания может решить, что слишком сильно педалировать новые разработки невыгодно или даже опасно. Например, в прошлом или позапрошлом году одна фармкомпания была оштрафована на миллиарды долларов, потому что было показано, что у неё были доказательства эффективности нового продукта, но она не выводила его на рынок, потому что успешно продавала старый, который был защищён патентом. Соответственно, компания ждала, когда истечет патент, чтобы вывести новый продукт. Компанию обвинили во множестве смертей, которые могли бы не случиться, если бы более эффективное лекарство вывели на рынок сразу. Так что если бы компания затягивала с экспериментальным продуктом, то исков удалось бы избежать. Это, на мой вкус, звучит кощунственно, но фармкомпании могут думать иначе. Там каждый новый продукт требуетс вложений миллиардов баксов. Поэтому компании стремятся максимально отработать инвестиции в старый продукт, прежде чем выводить новый
В общем, мотивов или объективных сложностей может быть много... Это неисчепаемая тема...
Спасибо за интерес! С удовольствием отвечу.
Я здесь не стал вдаваться в полную историю того продукта. Полный жизненный цикл там, конечно же, был довольно сложный. Более того, первые наработки по тому продукту появились за 8 лет до релиза, но затем на 5 с лишним лет разработка была заморожена по определённым причинам, которые я не могу здесь озвучивать (но кое-что скажу ниже, в следующем комментарии...) В общем, там и concept proof был, и иследование потребительского спроса, и многочисленные изменения в концепции, и отработка отдельных технологических этапов... Но это всё совсем другая история, которая увела бы нас в сторону от основной. Главное, что разработка на любых этапах велась в отрыве от финального вИдения продукта даже за 6 месяцев до релиза. Более того, финального вИдения вообще не существовало. Да, там идеально были отработаны отдельные технологические операции (которые по большей части осуществлялись софтом). Но вопросы интеграции, вписывания в существующую инфраструктуру, взаимодействия с клиентом и т.д. и т.п. не были проработаны совсем.
Конкретно я считаю, что разработка даже concept-proof версий не должна происходить совсем уж в вакууме. Всегда должно быть какое-то вИдение финальной архитектуры. Да, оно может быть неполным, может изменяться хоть каждый день, но оно должно быть. И разработка на любом шаге (возможно, кроме самого-самого начального) должна соответствовать общей архитектурной канве. Там могут быть отсутствующие "куски", могут быть упрощенные, но общая архитектура должна выдерживаться (даже если она периодически изменяется). И вопросы связывания отдельных "блоков" решения в общую картину должны прорабатываться так же, как и сами блоки/операции по отдельности. Именно в такой парадигме мне посчастливилось всегда работать вплоть до описанного случая.
Ого! Даже такое бывает?
Если учесть, что нейросетки в целом "склонны" льстить, подчёркивать правоту и мотивировать, то вырисовывается так себе картинка... Это если руководитель опирается исключительно на "мнение" сетки или ставит его выше всего...
В целом, думаю, нет ничего зазорного спросить что-то у нейронки. Но надо держать в уме, что нейронка может льстить, ошибаться, что нужно посоветоваться с экспертами-людьми и что если есть расхождения, то неплохо бы запросить аргументацию и у тех, и у других :)
Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Спасибо за подробный рассказ о вашем подходе! Очень интересно!
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Спасибо за интерес!
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
Ого! Фудаментально :) Спасибо за примеры!
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Спасибо за отклик!
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин:
1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях
2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату
3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Спасибо за интерес!
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...