Здравствуйте, IT, Вы писали:
IT>Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.
Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
P>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.
Еще раз повторю, ни разу подобного не видел. Более того, сравнивать зачастую стоит не столько команды, сколько конкретных людей, которые команду образуют. Достаточно одного сильного инженера с талантом преподавателя, чтобы команда оценила и полюбила незнакомый стек. Достаточно одного брюзги с нежеланием учиться ничему новому, поставленного в позицию сеньора, чтобы та же команда стала сборищем тормозов.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
·>Эээ.. пхп же остался. А вот лисп переписали и лиспа не осталось вообще.
Где остался-то? Уж точно не в Facebook'е. Гуглить по словам "Hack" (форк PHP).
SD>>Более того, PHP как язык не поддерживается вообще.
...но это не в Фейсбуке. Лисп вне Yahoo тоже жив.
SD>>В то же время другие языки — как тот же Haskell или Erlang — используются очень широко, и без переписывания всей кодовой базы. ·>Stable release Haskell 2010[2] / July 2010; 11 years ago
Внимательнее смотри.
27 May 2022
GHC 9.2.3 Released! [download]
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно.
Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, so5team, Вы писали:
S>Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?
Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны.
Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, SkyDance, Вы писали:
P>>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.
SD>Еще раз повторю, ни разу подобного не видел.
Значит, мало видел.
> Более того, сравнивать зачастую стоит не столько команды, сколько конкретных людей, которые команду образуют. Достаточно одного сильного инженера с талантом преподавателя, чтобы команда оценила и полюбила незнакомый стек. Достаточно одного брюзги с нежеланием учиться ничему новому, поставленного в позицию сеньора, чтобы та же команда стала сборищем тормозов.
Вот-вот. Снова противоречие. Нужно сравнивать не коней в вакууме, а эффективность с т.з. решения проблемы целиком, от начала работ до финала деливери.
Все остальное, типа "я закодил фичу в 100500 раз быстрее" на общем фоне неразличимы.
Все достаточно просто — перформанс команды == перформанс ботлнека. И вот такая штука, что код бывает ботлнеком не так уж и часто. Гораздо чаще таким ботлнеком будет обеспечение качества, менеджмент и тд. Например, мега-менеджер решил, что им тестировщики не нужны. Ну ок. Значит вся команда начинает потиху отрываться от реальности, независимо от квалификации. Рано или поздно все это приводит к тому, что продукт заполняется вечноживыми багами.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.
У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны. Z>Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.
Вот-вот. Шериданство в чистом виде.
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Pauel, Вы писали:
P>У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.
Это какие-то твои проекции. Здесь нет ничего про вину. Здесь про то, что умеют и чем руководствуются менеджеры. Я сам менеджер, если что и мне нафиг не нужны трудовые подвиги ни мои ни командные. Работа по выжиманию всего из требований, стека и архитектуры результативная, но очень слабо предсказуемая, а это мало кому интересно. Более того, это может удлинить какие-то промежуточные этапы, плохо попадает в оценку и сложно ложится в проектную деятельность.
Я по опыту знаю, что собрать крутую команду и создать ей крутой продукт за цену в разы меньшую чем по корпоративным расценкам можно. И знаю, насколько проще создавать продукты в корпорации, пусть и в разы дольше и дороже, но это никого особо не парит, едем по рельсам и все. Просто потому, что по другому никто не готов и страшно узнать, что это вообще возможно.
Это мой опыт и если все что тебе остается — переходить на личности, то избавь меня от такого чтения. Себя же дураком выставляешь, у которого бомбит от того, что кто-то может по другому и срочно надо опровергнуть.
Re[6]: Так, господа, а вот это уже серьезно (Haskell нужен 2
Здравствуйте, vsb, Вы писали:
vsb>В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет
Это continuations то в других языках нет? Или другие языки у тебя строго равны java?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем.
Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.
Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях.
Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Pauel, Вы писали:
P>Вот-вот. И нужно теперь гарантировать, что этих людей ты сможешь вовремя заменить.
Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.
P>Как то так выходит, что команда крутых спецов на старте означает переписывание всего подряд с версии 2.0. Вот пример с Лиспом он как раз это и продемонстрировал.
Не выходит. Но заменять людей и расставаться с ними в любом случае надо уметь.
Re[20]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.
Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.
Управлять 5 профи все равно нужно и все управленческие проблемы с ними уникальны. А 50 развиздяев так или иначе по проторенным практикам будут выдавать что-то полезное и управлять надо не всеми ими, а несколькими лидами и требованиями к продукту и коду. В этих требованиях лучше запретить всякие непонятные штуки, так как при неумелой доработке они стреляют в ноги всей команде и никакое ревью не спасает.
НС>Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях. НС>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.
Именно это я и говорю. Большим конторам редко нужны такие кейсы по вполне понятным и обоснованным причинам. Но там где они применяются, хорошую экономию дает и стек и умелое использование его особенностей. А именно это пытаются здесь оспорить некоторые как "не бывает, а если бывает, то все равно говно получается".
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, so5team, Вы писали:
S>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?
Из собственного.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
Z>Управлять 5 профи все равно нужно
Только стратегически, чтобы они выдерживали курс. Иначе это не профи.
НС>>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части. Z>Именно это я и говорю.
Но причины этого ты приводишь какие то фантастические.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
S>>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?
Z>Из собственного.
Очень и очень странно. Возможно, вам повезло. Возможно, вы просто не отрефлексировали свое собственное развитие в менеджменте и судите о сложности управления коллективом из 100 человек не учитывая опыта, которого у вас не было когда вы управляли коллективом из 10 человек.
Re[21]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.
Если ресурсов на разработку с запасом, да, высока. Сейчас достаточно практик наработано. Можем конечно пободаться за термины гарантии/вероятности, но не вижу смысла.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
Здравствуйте, Ziaw, Вы писали:
НС>>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.
Z>Управлять 5 профи все равно нужно и все управленческие проблемы с ними уникальны.
Обычно такие команды максимально автономны. Им сообщают приоритеты, новые фичи и всё. Т.е. участие менеджера сводится к минимуму.
Проблемой может быть говно- и микроменеджмент — тогда команда профи может как разбежаться, так и "сожрать" менеджера. Мне, скажем, известен случай, когда когда проектная команда из таких профи сожрала не одного, а целый страйк менеджеров.
Например,
1 прибегает менеджер и вопит "..я, чего ты тут занимаешься этим, это уже не надо..." ? А откуда разработчику знать, что не надо, если тикет ему только вчера выдан?
2 Или так "..я, почему бакенды коммитают раз в день, а фронтенды по 10-15 раз в день" и начинает "ускорять", потому что по его мнению бакенды тупые и ленивые, а фронтенды — хорошие и годные.
3 Или вот кейс "на текущий спринт приоритет — десктоп!!!!1111" и всем тикеты по андроиду. Следующий спринт — "приоритет андроид!!!!1" и тут же менеджер требует "мне срочно нужен релиз десктопа"
4 А вот еще "напиши вот такой код, должно работать", "если сеть ненадежна, то пусть админы сделают её надежной" — это менеджер объясняет разработчику с 15ю лет опыта, что можно писать код так, как будто сеть 100% надежна.
Итого 1 — сожран, 2 — сожран, 3 — сожран, 4 — сожран. А продукт взлетел, несмотря на "менеджеров"